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Introduction 

The Small Computer System Interface (SCSI) command set is widely used and applicable to a wide variety of 
device types. The transmission of SCSI command set information across an RDMA communication service 
allows the large body of SCSI application and driver software to be successfully used on the InfiniBand™ 1 
Architecture, the VI Architecture and other interfaces that support RDMA communication service semantics. 
The SCSI RDMA Protocol-2 (SRP-2) standard is divided into the following clauses: 

Clause 1 is the scope. 

Clause 2 enumerates the normative references that apply to this standard. 

Clause 3 describes the definitions, symbols, abbreviations, and conventions used in this standard. 

Clause 4 describes the RDMA communication service model. 

Clause 5 describes significant concepts of SRP. 

Clause 6 describes the information units used by SRP. 

Clause 7 defines the SCSI management features for SRP, including the SRP mode pages. 

Annex A and Annex B form an integral part of this standard. 
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INCITS.***:200x 


American National Standard for Information Systems - 
Information Technology - 

SCSI RDMA Protocol-2 (SRP-2) 

1 Scope 

The SCSI family of standards provides for many different transport protocols that define the rules for exchanging 
information between different SCSI devices. This standard defines the rules for exchanging information between 
SCSI devices using an RDMA communication service. Other SCSI transport protocol standards define the rules 
for exchanging information between SCSI devices using other interconnects. 

The set of SCSI standards specifies the interfaces, functions and operations necessary to ensure 
interoperability between conforming SCSI implementations. This standard is a functional description. 
Conforming implementations may employ any design technique that does not violate interoperability. 

Figure 1 shows the relationship of SCSI transport protocol standards, such as this one, to the other standards 
and related projects in the SCSI family of standards as of the publication of this standard. 



Figure 1 - SCSI document relationships 


Figure 1 is intended to show the general relationship of the documents to one another. Figure 1 is not intended 
to imply a relationship such as a hierarchy, protocol stack or system architecture. It indicates the applicability of 
a standard to the implementation of a given transport. 

At the time this standard was generated, examples of the SCSI general structure included: 

Interconnects: 

SCSI Parallel Interface - 4 
Serial Storage Architecture Physical Layer 1 
Serial Storage Architecture Physical Layer 2 

SCSI Transport Protocols: 

Serial Storage Architecture Transport Layer 1 
Serial Storage Architecture Transport Layer 2 
SCSI Parallel Interface - 2 


SPI-4 

[ANSI INCITS.362-200X] 

SSA-PH 

[ANSI X3.293:1996] 

SSA-PH-2 

[ANSI NCITS.307:1998] 

SSA-TL-1 

[ANSI X3.295:1996] 

SSA-TL-2 

[ANSI NCITS.308:1998] 

SPI-2 

[ANSI X3.302-1998] 
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SCSI Fibre Channel Protocol - 2 

FCP-2 

[T10/1144D] 

1 

SCSI Serial Bus Protocol - 2 

SBP-2 

[ANSI NCITS.325-1998] 

2 

Serial Storage Architecture SCSI-3 Protocol 

SSA-S3P 

[ANSI NCITS.309-1998] 

3 

Shared Command Sets: 



4 

SCSI Primary Commands-3 

SPC-3 

[T10/1416D] 

5 

6 

Device-Type Specific Command Sets: 



7 

8 

SCSI-3 Block Commands 

SBC 

[ANSI NCITS.306-1998] 

9 

SCSI-3 Enclosure Services 

SES 

[ANSI NCITS.305-1998] 

10 

SCSI-3 Stream Commands 

SSC 

[ANSI NCITS.335:2000] 

11 

SCSI-3 Medium Changer Commands 

SMC 

[ANSI NCITS.314:1998] 

12 

SCSI Multimedia Command Set - 2 

MMC-2 

[ANSI NCITS.333:2000] 

13 

SCSI Controller Commands - 2 

SCC-2 

[ANSI NCITS.318:1998] 

14 

Object-based Storage Devices Commands 

OSD 

[T10/1355-D] 

15 

Architecture Model: 



16 

SCSI Architecture Model - 2 

SAM-2 

[T10/1157D] 

17 


18 


The term SCSI is used to refer to the family of standards described in this clause. 

2 Normative references 

2.1 Normative references 

The following standards contain provisions that, by reference in the text, constitute provisions of this standard. 
At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to 
agreements based on this standard are encouraged to investigate the possibility of applying the most recent 
editions of the standards listed below. 

Copies of the following documents may be obtained from ANSI: approved ANSI standards, approved and draft 
international and regional standards (ISO, IEC, CEN/CENELEC, ITUT), and approved and draft foreign 
standards (including BSI, JIS, and DIN). For further information, contact ANSI Customer Service Department at 
+1.212.642.4900 (telephone), +1.212.302.1286 (facsimile) or via the World Wide Web at http://www.ansi.org. 
Additional availability contact information is provided below as needed. 

2.2 Approved references 

ISO/IEC 14776-312, SCSI Primary Commands - 2 (SPC-2) [ANSI NCITS.351:200x] 

2.3 References under development 

At the time of publication, the following referenced standards were still under development. For information on 
the current status of the document, or regarding availability, contact the relevant standards body or other 
organization as indicated. 

ISO/IEC 14776-412, SCSI Architecture Model - 2 (SAM-2) [T10/1157-D] 

ISO/IEC 14776-313, SCSI Primary Commands - 3 (SPC-3) [T10/1416-D] 

NOTE 1 - For more information on the current status of a document, contact the INCITS Secretariat at 
+1.202.737.8888 (phone), +1.202.638.4922 (fax) or via Email at ncits@itic.org. To obtain copies of these 
documents, contact Global Engineering at 15 Inverness Way, East Englewood, CO 80112-5704 at 
+1.303.792.2181 (phone), 1.800.854.7179 (phone), or+1.303.792.2192 (fax), or at http://global.ihs.com . 
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3 Definitions, symbols, abbreviations and conventions 

3.1 Definitions 

3.1.1 acceptance data: Application protocol data communicated from a server consumer to the client 
consumer when a new RDMA channel is accepted (see XX). This protocol uses acceptance data to 
communicate the SRP_LOGIN_RSP response (see 6.3). 

3.1.2 application client: An object that is the source of SCSI commands (see SAM-2). 

3.1.3 byte: An 8-bit construct. 

3.1.4 channel attributes: Information provided during RDMA channel establishment that identifies the type 
and characteristics of the desired RDMA channel (see XX). The format and interpretation of channel attributes 
are specific to a particular RDMA communication service. 

3.1.5 command: A request describing a unit of work to be performed by a device server (see SAM-2). 

3.1.6 command descriptor block (CDB): The structure used to communicate commands from an 
application client to a device server (see SPC-2). 

3.1.7 consumer: An object that communicates with other consumers using an RDMA communication service 
(see XX). In this protocol, a consumer is either an SRP target port or an SRP initiator port. 

3.1.8 data-in buffer: The buffer identified by the application client to receive data from the device server 
during the execution of a command (see SAM-2). 

3.1.9 data-out buffer: The buffer identified by the application client to supply data that is sent from the appli¬ 
cation client to the device server during the execution of a command (see SAM-2). 

3.1.10 device server: An object within a logical unit that executes SCSI tasks according to the rules of task 
management (see SAM-2). 

3.1.11 information unit: An organized collection of data specified by this protocol to be transferred as login 
data, rejection data, acceptance data, or a message on an RDMA channel. 

3.1.12 initiator interconnect port: An object, resident in the interconnect layer, that connects the SCSI 
initiator port to the interconnect through which messages and data transfer requests and responses are routed. 

3.1.13 initiator port identifier: A value by which a SCSI initiator port is referenced within a domain (see 
SAM-2). 

3.1.14 interconnect nexus: An association between an initiator interconnect port (see 3.1.12) and a target 
interconnect port (see 3.1.34) such that messages and data transmitted by one interconnect port will delivered 
to the other interconnect port. 

3.1.15 interconnect port: An interconnect layer-resident object that connects the SCSI port to the 
interconnect through which lUs and data transfer requests and responses are routed. Interconnect port is 
synonymous with either a initiator interconnect port (see 3.1.34) or a target interconnect port (see 3.1.34). 

3.1.16 logical unit: A target-resident object that implements a device model and processes SCSI commands 
sent by an application client. 

3.1.17 logical unit number (LUN): A 64-bit identifier for a logical unit (see SAM-2). 

3.1.18 login data: Data communicated from a client consumer to a server agent or server consumer during 
RDMA channel establishment (see XX) that is meaningful within the client/server application protocol. This 
protocol uses login data to communicate the SRP_LOGIN_REQ request (see 6.2). 

3.1.19 message: A communication sent by one consumer to another using an RDMA channel 
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3.1.20 RDMA channel: A communication path between two consumers of an RDMA communication service i 

(see xx). 2 

3.1.21 RDMA communication service: The software, protocols, and interconnect that provides 
message and RDMA operations between pairs of consumers (see clause 4). 

3.1.22 RDMA operation: Either an RDMA Read operation or an RDMA Write operation. 

3.1.23 RDMA Read operation: An operation by which a requesting consumer may fetch data from memory 
registered by the other consumer associated with an DMA channel (see XX). 

3.1.24 RDMA Write operation: An operation by which a requesting consumer may store data into memory 
registered by the other consumer associated with an 

3.1.25 rejection data: Application protocol data communicated from a server agent or server consumer to the 12 

client consumer when a new RDMA channel is rejected (see XX). This protocol uses rejection data to 13 

communicate the SRP_LOGIN_REJ response (see 6.4). 14 

3.1 .26 sense data: Data returned to an application client in the sense data field of an SRP RSP response-er 
an SRP AER REQ r e u e st . See SAM-2. 

3.1.27 server agent: An entity that provides services (e.g., connection management) on behalf of a server 
consumer. 

3.1.28 server identifier: Information provided to an RDMA communication service by a client consumer that 
allows the RDMA communication service to locate the desired server consumer. The format and interpretation 
of a server identifier are specific to the RDMA communication service. 

3.1.29 SRP initiator port: A SCSI initiator port that uses this protocol to communicate with an SRP target port. 

24 

3.1.30 SRP initiator port identifier: A value by which an SRP initiator port is identified to an SRP target port. 

3.1.31 SRP target port: A SCSI target port that uses this protocol to communicate with an SRP initiator port. 

27 

3.1.32 SRP target port identifier: A value by which an SRP target port is identified within an SRP domain. 

3.1.33 status: Response information sent from a device server to an application client upon completion of 
each command (see SAM-2). 

3.1.34 target interconnect port: An object, resident in the interconnect layer, that connects the SCSI target 
port to the interconnect through which messages and data transfer requests and responses are routed. 

33 

3.1.35 target port identifier: A value by which a SCSI target port is referenced within a domain (see SAM-2). 

35 

_ „ 36 

3.2 Acronyms 

CDB Command Descriptor Block (see 3.1.6) 

INCITS InterNational Committee for Information Technology Standards 

LSB Least significant bit 

LUN Logical Unit Number (see 3.1.17) 

43 

MSB Most significant bit 

NCITS National Committee for Information Technology Standards (now INCITS) 

RDMA Remote Direct Memory Access 

47 

SAM-2 SCSI Architecture Model - 2 (see 2.3) 

SCSI The architecture defined by the family of standards described in clause 1 

50 
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SPC-2 SCSI Primary Commands - 2 (see 2.3) 

SRP SCSI RDMA Protocol (this standard) 

3.3 Keywords 

3.3.1 expected: A keyword used to describe the behavior of the hardware or software in the design models 
assumed by this standard. Other hardware and software design models may also be implemented. 

3.3.2 ignored: A keyword used to describe an unused bit, byte, word, field or code value. The contents or 
value of an ignored bit, byte, word, field or code value shall not be examined by the receiving SCSI device and 
may be set to any value by the transmitting SCSI device. 

3.3.3 invalid: A keyword used to describe an illegal or unsupported bit, byte, word, field or code value. 
Receipt of an invalid bit, byte, word, field or code value shall be reported as an error. 

3.3.4 mandatory: A keyword indicating an item that is required to be implemented as defined in this 
standard. 

3.3.5 may: A keyword that indicates flexibility of choice with no implied preference (equivalent to "mayor may 
not"). 

3.3.6 may not: Keywords that indicate flexibility of choice with no implied preference (equivalent to "may or 
may not"). 

3.3.7 obsolete: A keyword indicating that an item was defined in prior SCSI standards but has been removed 
from this standard. 

3.3.8 optional: A keyword that describes features that are not required to be implemented by this standard. 
However, if any optional feature defined by this standard is implemented, then it shall be implemented as 
defined in this standard. 

3.3.9 reserved: A keyword referring to bits, bytes, words, fields and code values that are set aside for future 
standardization. A reserved bit, byte, word or field shall be set to zero, or in accordance with a future extension 
to this standard. Recipients are not required to check reserved bits, bytes, words or fields for zero values. 
Receipt of reserved code values in defined fields shall be reported as an error. 

3.3.10 restricted: A keyword referring to bits, bytes, words, and fields that are set aside for use in other SCSI 
standards. A restricted bit, byte, word, or field shall be treated as a reserved bit, byte, word or field for the 
purposes of the requirements defined in this standard. 

3.3.11 shall: A keyword indicating a mandatory requirement. Designers are required to implement all such 
mandatory requirements to ensure interoperability with other products that conform to this standard. 

3.3.12 should: A keyword indicating flexibility of choice with a strongly preferred alternative; equivalent to the 
phrase “it is strongly recommended”. 


3.4 Conventions 

Certain words and terms used in this standard have a specific meaning beyond the normal English meaning. 
These words and terms are defined either in 3.1 or in the text where they first appear. 

Names of commands, statuses, sense keys, additional sense codes and additional sense code qualifiers are in 
all uppercase (e.g., REQUEST SENSE). 

Names of fields and state variables are in small uppercase (e.g. allocation length). When a field or state 
variable name contains acronyms, uppercase letters may be used for readability (e.g. NormACA). Normal case 
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is used when the contents of a field or state variable are being discussed. Fields or state variables containing 
only one bit are usually referred to as the name bit instead of the name field. 

Normal case is used for words having the normal English meaning. 

Numbers that are not immediately followed by lower-case b or h are decimal values. 

Numbers immediately followed by lower-case b (e.g. 0101b) are binary values. 

Numbers or upper case letters immediately followed by lower-case h (e.g. FA23h) are hexadecimal values. 
Lists sequenced by letters (e.g., a-red, b-blue, c-green) show no ordering relationship between the listed items. 
Numbered lists (e.g., 1-red, 2-blue, 3-green) show an ordering between the listed items. 

If a conflict arises between text, tables or figures, the order of precedence to resolve the conflicts is text; then 
tables; and finally figures. Not all tables or figures are fully described in the text. Tables show data format and 
values. 

Notes do not constitute any requirements for implementors. 

3.5 Notation for procedures and functions 

In this standard, the model for functional interfaces between objects is the callable procedure. Such interfaces 
are specified using the following notation: 

[Result =] Procedure Name (IN ([input-1] [,input-2] ...]), OUT ([output-1] [,output-2] ...)) 

Where: 


A single value representing the outcome of the procedure or function. 

A descriptive name for the function to be performed. 

A comma-separated list of names identifying caller-supplied input data objects. 

A comma-separated list of names identifying output data objects to be returned 
by the procedure. 

Brackets enclosing optional or conditional parameters and arguments. 

This notation allows data objects to be specified as inputs and outputs. The following is an example of a 
procedure specification: 

Found = Search (IN (Pattern, Item List), OUT ([Item Found])) 

Where: 

Found = Flag 

Flag, which, if set, indicates that a matching item was located. 

Input Arguments: 

Pattern = ... /* Definition of Pattern object 7 
Object containing the search pattern. 

Item List = ltem<NN> /* Definition of Item List as an array of NN Item objects*/ 

Contains the items to be searched for a match. 

Output Arguments: 

Item Found = Item ... /* Item located by the search procedure 7 
This object is only returned if the search succeeds. 


Result 
Procedure Name 
Input-1, Input-2, ... 

Output-1, Output-2, ... 
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4 RDMA communication service model 
4.1 Layering 

As shown in figure 2, a SCSI transport protocol, in this case, the SCSI RDMA Protocol, provides protocol 
services to the SCSI Application Layer above. To fulfill these requests, the SCSI RDMA Protocol instance 
makes interconnect service requests to the interconnect layer through the interconnect service interface. This 
clause describes, in a manner similar to the SAM-3 SCSI transport protocol services in support of Execute 
Command subclause, the interconnect services and the interconnect service interface for an interconnect that 
supports this protocol. 


Initiator I/O System 


Target I/O System 


SCSI Application 
Layer 


SCSI Protocol 
Layer 


Interconnect 

Layer 



SAM and 
Command 
Standards 


SCSI 

RDMA 

Protocol 


Interconnect 

Standard 


Figure 2 - Protocol service reference model 


4.2 Interconnect model 

4.2.1 Channels 

An interconnect channel is an exclusive association between two interconnect ports (see figure 3). The 
characteristics of interconnect channels are described in 4.3. 

4.2.2 Messages 

Information units (not data) are exchanged between initiators and targets through Send operations, whereby 
the interconnect delivers a sender-specified set of bytes to the recipient, which specifies the placement of the 
sent data within its memory space. The object that contains the placement specification is called a receive 
descriptor. One receive descriptor is consumed for each received message. 

4.2.3 Memory 

In this protocol, the initiator gives the target access to some of the initiator’s memory for target-initiated remote 
direct memory access operations (i.e., rdma write and rdma read) to effect the transfer of data-in and/or data- 
out. 


4.2.4 RDMA operations 

There are two rdma operations, rdma write and rdma read, which may ??? between the interconnect ports of 
an interconnect channel. An rdma write operation copies data from local memory to the memory of the remote 
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device. An rdma read operation copies data from local memory to the memory of the remote device. The 
ability to perform an rdma operation on a particular remote memory location is limited by the access rights 
granted by the remote device. 


Initiator Device Target Device 



Interconnect Channel 


Figure 3 - Object mapping model 

4.3 Interconnect services 
4.3.1 Introduction 

This clause defines the services that shall be provided by the interconnect service interface of an interconnect 
supporting this protocol. Some services are only meaningful and only required for initiators or for targets, and 
are thus indicated. If there is such an indication, it is only required as indicated. 

Interconnect protocol services support the SCSI protocol services defined in SAM-2. As an example, to fulfill 
the SCSI protocol request Send Command Complete, an SRP target issues the Send Message interconnect 
service request to send the information unit constructed from the Send Command Complete parameters. 

The message and data transfer services are based on the 1:1 nature of an interconnect nexus, so that by 
specifying the local interconnect port in a message or data interconnect service request, the remote port is 
implicitly specified. 
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4.3.2 Messages | 

4.3.3 RDMA Write 

4.3.4 RDMA Read 

4.3.5 Connection Services 

4.4 Interconnect characteristics 

4.4.1 Reliability 

The interconnect layer shall deliver each message to the SRP layer once, without duplication, complete and 
without error, and the interconnect layer shall deliver an interconnect-layer acknowledgement to the requester. 

If the interconnect layer cannot do so, it shall deliver an error notification to the requester and destroy the 
interconnect nexus. 

The interconnect layer shall deliver the data transferred by an RDMA Read or RDMA Write without error, and 
shall deliver an acknowledgement to the requestor. If the interconnect layer cannot do so, it shall deliver an 
error notification to the requester and destroy the interconnect nexus. 

4.4.2 Ordering 

There is no requirement for ordering on different interconnect port nexuses. All ordering references in this 
subclause are with respect to a single interconnect nexus. 

Messages sent on an interconnect nexus shall be delivered to the receiving consumer in the order they were 
sent. 

Interconnect ports shall process RDMA Write and Send requests in the order received. Interconnect ports 
may process RDMA Write and Send requests before RDMA Read requests, but shall not process an RDMA 
Read request before previously received RDMA requests. 

Messages sent on an interconnect nexus shall be delivered to the receiving consumer in the order they were 
sent. 

The data for all RDMA Write operations requested on an interconnect nexus by a consumer prior to that same 
consumer sending a message on the same interconnect nexus shall be available to the receiving consumer 
(e.g. stored into registered memory) before the message is delivered to the receiving consumer. The order in 
which multiple RDMA Writes (without an intervening message) are applied to a particular memory location is 
specific to the RDMA communication service. 

Messages sent on different interconnect nexuses may be delivered in any order. The data for RDMA Write 
operations may be stored into registered memory in any order relative to the delivery of messages sent on 
other interconnect nexuses. RDMA Write operations requested on different interconnect nexuss may store 
data into the same registered memory location in any order. 

RDMA Read operations may be processed in any order. 

If an RDMA communication service fails to meet the ordering requirements of this subclause on an 
interconnect nexus, it shall destroy the interconnect nexus. 

4.4.3 Memory Access 

The interconnect layer shall perform no RDMA Read or RDMA Write operation for which the memory 
descriptor is invalid. 
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5 Structure and concepts 

2 

5.1 Overview of SRP operation 

EDITOR’S NOTE 1 - This subclause will change as support for multiple channels develops. 

5.1.1 RDMA channel establishment and login 

SRP initiator ports login with SRP target ports when a new RDMA channel is established for use with this 
protocol. The login process associates an RDMA channel with a specific SRP initiator port and SRP target port 
(i.e., an l_T nexus (see SAM-2)) and negotiates parameters that govern the use of that RDMA channel. 

SRP initiator ports and SRP target ports shall be determined by their role during RDMA channel establishment. 

An object that requests RDMA channel establishment as a client consumer (see xx) shall be an SRP initiator 
port. An object that accepts RDMA channel establishment as a server consumer shall be an SRP target port. 

13 

Login occurs during RDMA channel establishment. An SRP initiator port shall provide an SRP_LOGIN_REQ 14 

request (see 6.2) as the login data when establishing a new RDMA channel. If an SRP target port accepts a 15 

new RDMA channel it shall provide an SRP_LOGIN_RSP response (see 6.3) as the acceptance data. If an SRP 16 

target port does not accept a new RDMA channel it shall provide an SRP_LOGIN_REJ response (see 6.4) as 17 

the rejection data when rejecting the new RDMA channel. 18 

The SRP LOGIN REQ request (see 6.2) contains an SRP initiator port identifier and an SRP target port 
identifier. An SRP target port shall not accept a new RDMA channel unless its SRP target port identifier is 
identical to the value in the SRP_LOGIN_REQ request. If an SRP target port accepts a new RDMA channel, it 
shall treat all communication on that RDMA channel as being with the SRP initiator port identified by the SRP 
initiator port identifier specified in the SRP_LOGIN_REQ request. 

5.1.2 Single RDMA channel operation 

An SRP initiator port may specify single RDMA channel operation during login. If an SRP target port accepts 
such a login, it shall: 

a) Attempt to send an SRP T LOGOUT request (see 6.6) on any established RDMA channel that 
specified the same SRP initiator port identifier. The reason code shall indicate that the RDMA channel 
was disconnected due to a multi-channel action code in a new SRP_LOGIN_REQ request (see 6.2); 

b) Request disconnection of any established RDMA channel (see 5.1.4) that specified the same SRP 
initiator port identifier; and 

c) Reject any other RDMA channel establishment requests it has received that specified the same SRP 
initiator port identifier and that the SRP target port has not yet accepted. 

Following acceptance of a login specifying single RDMA channel operation, that single RDMA channel shall be 
used for all communication between the specified SRP initiator port and SRP target port. Subsequent logins 
specifying other modes of operation may allow communication using multiple RDMA channels. 

When an l_T nexus is using this protocol in the single RDMA channel mode, these events are l_T nexus loss 
notification events (see SAM-2, SPC-3): 

a) Sending or receiving an SRP_l_LOGOUT request or an SRP_T_LOGOUT request; 

b) Requesting that an RDMA channel be disconnected; or 

c) Receiving notification that an RDMA channel has been disconnected. 

44 

5.1.3 Multiple independent RDMA channel operation 

An SRP initiator port may specify multiple independent RDMA channel operation during login. An SRP target 
port shall not accept such a login if doing so would require disconnecting an established RDMA channel with 
the same SRP initiator port, and shall return the SRP_T_LOGOUT request reason code RDMA channel limit 
REACHED FOR THIS INITIATOR. 
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Following acceptance of a login specifying multiple independent RDMA channel operation, one or more RDMA 
channels may be used for communication between the SRP initiator port and the SRP target port. All such 
RDMA channels are associated with the single l_T nexus defined by the SRP initiator port identifier and the SRP 
target port identifier. 

When multiple independent RDMA channels are used, operation of each SRP request is confined to a single 
RDMA channel. The sender of an SRP request chooses an RDMA channel to use for sending the SRP request. 
The sender of an SRP response shall use the same RDMA channel as the SRP request for sending the SRP 
response. All RDMA operations associated with the SRP request shall also use the same RDMA channel as the 
SRP request. 

While each SRP request is confined to a single RDMA channel, SCSI tasks and task management functions 
may be conveyed on independent RDMA channels associated with the same l_T nexus. SCSI tasks and task 
management functions interact as specified by SAM-2, SPC-2 and other SCSI command standards (e.g., within 
an l_T nexus, a SCSI task sent on one RDMA channel may be aborted by an ABORT TASK sent on a different 
RDMA channel.) 

An RDMA communication service may not provide any ordering relationship between SRP requests, SRP 
responses and RDMA operations that use different RDMA channels. If ordering is important for a sequence of 
SRP requests, they should be sent using the same RDMA channel. 

When an l_T nexus is using this protocol in the multiple independent RDMA channel mode, these events are 
I T nexus loss notification events (see SAM-2, SPC-3) when they occur with respect to the last (or only) channel 
associated with the I T nexus: 

a) Sending or receiving an SRP_l_LOGOUT request or an SRP_T_LOGOUT request; 

b) Requesting that an RDMA channel be disconnected; or 

c) Receiving notification that an RDMA channel has been disconnected. 

5.1.4 RDMA channel disconnection 

RDMA channel disconnection may cause (see 5.1.2 and 5.1.3) an I T nexus loss notification event as described 
in SAM-2 and SPC-3. 

An SRP initiator port should send an SRP I LOGOUT request (see 6.5) and wait for the RDMA communication 
service status indication (see XX) before requesting that an RDMA channel be disconnected. 

After requesting that an RDMA channel be disconnected, after being notified that an RDMA channel has been 
disconnected, or upon receiving an SRP_T_LOGOUT request (see 6.6), an SRP initiator port shall: 

a) Discard any outstanding request received from an SRP target port on that RDMA channel, without 
returning a response; 

b) Not send any further messages on that RDMA channel; 

c) Discard any subsequent messages received on that RDMA channel; and 

d) For any outstanding SCSI tasks sent on that RDMA channel, indicate to the application client that the 
task has terminated with a service delivery system failure. 

An SRP target port should send an SRPTLOGOUT request (see 6.6) and wait for the RDMA communication 
service status indication (see XX) before requesting that an RDMA channel be disconnected. 

After requesting that an RDMA channel be disconnected, after being notified that an RDMA channel has been 
disconnected, or upon receiving an SRP_l_LOGOUT request (see 6.5), an SRP target port shall: 

a) Abort all outstanding SCSI tasks that were contained in SRP_CMD requests (see 6.8) received on that 
RDMA channel, without returning a response; 

b) Discard any other outstanding requests received from an SRP initiator port on that RDMA channel, 
without returning a response; 

c) Not send any further messages on that RDMA channel; 
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d) Discard any subsequent messages received on that RDMA channel; and 

e) Not alter previously established conditions, including MODE SELECT parameters, reservations, ACA, 
and CA as a result of the disconnection. 

5.2 Identifiers 

5 

Initiator port identifiers and target port identifiers (see SAM-2) for this protocol are 16 bytes in length. 

5.3 Alias associations 

8 

There are no events specific to this protocol that clear alias associations (see SPC-2). 

5.4 Information unit classes 

ii 

Each SRP information unit is classified as an SRP request (see table 5 and table 7) or an SRP response (see 
table 6 and table 8). SRP requests convey SCSI commands, task management requests and RDMA channel 
management requests. SRP responses convey SCSI command and task management service responses and 
RDMA channel management responses. RDMA channel management requests may be issued by SRP target 
ports or SRP initiator ports. 

In normal operation, SRP requests and SRP responses occur in pairs. Each SRP request elicits a single 
corresponding SRP response from the SRP device receiving the SRP request. An SRP request communicates 
the start of a remote procedure call; the corresponding SRP response communicates the remote procedure 
call’s completion. 

An SRP response shall not be returned: 

a) for an SRP_CMD request if the associated task is aborted; 

b) for an SRP_T_LOGOUT request (see 6.6); 

c) for an SRP_l_LOGOUT request (see 6.5); and 

d) for outstanding SRP requests received on an RDMA channel when an SRP device becomes aware of 
a failure preventing further communication on that RDMA channel. In this case, the device shall abort 
all outstanding SRP requests received on that RDMA channel. 

In all other cases an SRP device shall return a single SRP response for each SRP request it receives. 

30 

SRP responses shall be sent on the RDMA channel on which the corresponding SRP request was received. 

5.5 SRP target port buffer management 

33 

5.5.1 Buffer management overview 

SRP target port buffer management allows an SRP target device to limit the number of SRP requests that may 
be sent on an RDMA channel. SRP devices may use SRP target port buffer management to manage internal 
and RDMA channel-related resources. 

SRP responses are not subject to buffer management; they may be sent at any time. An SRP device may limit 
the number of SRP responses it may receive by limiting the number of SRP requests it has outstanding. 

40 

5.5.2 SRP requests issued by target port 

SRP target ports shall limit themselves to one outstanding SRP request (see table 7) per RDMA channel. Upon 
sending an SRP request, an SRP target port shall not send another SRP request on the same RDMA channel 
until after it receives the SRP response (see table 8) for the previous SRP request. 

5.5.3 Requests issued by initiator port 

This protocol uses a credit-based buffer management algorithm to limit the number of SRP requests (see table 
5) that an SRP initiator port may send to an SRP target port. The algorithm uses a field, request limit delta, 
that is present in most information units sent by an SRP target port to an SRP initiator port (not in 
SRP_LOGIN_REJ or SRP_T_LOGOUT), and a state variable, request limit. 
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Most information units containing a request limit delta field do not generate a confirmation that the SRP 
initiator port has received the information unit and processed the contents of the request limit delta field. The 
SRP_CRED_REQ (see 6.10) and SRP AER REQ (s ee 6.12) requests does generate a confirmation through 
the SRPCREDRSP (see 6.11) and SRP AER RSP (s ee 6.13) response s r e sp e ct i v el y . An SRP initiator port 
shall process the request limit delta fields of information units received on an RDMA channel in the order that 
they are received. An SRP initiator port shall process the request limit delta field of a request before sending 
that request’s response, (e.g., An SRP initiator port shall process the request limit delta field of an 
SRP_CRED_REQ request before sending the SRPCREDRSP.) The following rules specify the buffer 
management algorithm for SRP requests sent by SRP initiator ports: 

a) The Request Limit and Request Limit Delta variables are both signed, two’s complement 32-bit integers. 
SRP initiator ports shall implement a separate copy of the request limit variable for each RDMA channel; 

b) Upon successful completion of RDMA channel establishment an SRP initiator port shall initialize the 
RDMA channel’s Request Limit variable to the value of the request limit delta field received in the 
SRP_LOGIN_RSP response (see 6.3). Except for providing an SRP_LOGIN_REQ request (see 6.2) 
when requesting RDMA channel establishment, the SRP initiator port shall not send any SRP 
information units on the RDMA channel prior to initializing the Request Limit variable; 

c) An SRP initiator port may send an SRP request on an RDMA channel when the value of the RDMA 
channel’s Request Limit variable is greater than zero. An SRP initiator port shall not send an SRP 
request on any RDMA channel whose Request Limit variable has a value less than or equal to zero; the 
results of doing so are vendor-specific. To ensure that task management requests may be sent, an SRP 
initiator port may choose to send commands only when the value of the Request Limit variable is greater 
than one; 

d) An SRP initiator port shall decrement an RDMA channel’s Request Limit variable by one whenever it 
sends an SRP request on that RDMA channel; 

e) An SRP initiator port shall add (two’s complement addition) the value of the request limit delta field 
to an RDMA channel’s Request Limit variable whenever it receives an information unit on that RDMA 
channel; and 

f) An SRP target port shall not specify a positive value of the request limit delta field that may cause 
the SRP initiator port’s Request Limit variable to exceed 2 30 ; and 

g) An SRP target port shall not specify a negative value for the request limit delta field in an information 
unit that may cause the SRP initiator port’s Request Limit variable to drop below -2 31 . 
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5.6 Data buffers 
5.6.1 Memory descriptors 

A memory descriptor is a 16-byte structure that identifies a memory segment (see table 1). Figure 4 illustrates 
the mapping of a memory descriptor to a memory segment. 


Table 1 - Memory descriptor 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

(MSB) 


VIRTUAL ADDRESS 

7 

(LSB) 

8 

(MSB) 


MEMORY HANDLE 

11 

(LSB) 

12 

(MSB) 


DATA LENGTH 

15 

(LSB) 


The virtual address field contains an unsigned integer value that identifies the byte address within the memory 
region of the first byte of the memory segment. 

The memory handle field contains an SRP initiator port-specific value that identifies the region that contains the 
memory segment. The SRP target port shall supply this value with any RDMA operation that accesses the 
memory segment. 

The data length field contains an unsigned integer value that identifies the length of the memory segment in 
bytes. The interpretation of a memory descriptor where the sum of the virtual address and data length fields 
exceeds 2 64 is vendor-specific. 

An SRP target port may use a memory descriptor for either RDMA Read operations or RDMA Write operations 
but not both. SRP target ports shall issue only the appropriate type of RDMA operation for a memory descriptor, 


Memory descriptor 


VIRTUAL ADDRESS 


MEMORY HANDLE 
DATA LENGTH 





Memory 

Memory region 

0 



3 

Memory segment 









Figure 4 - Memory descriptor mapping 
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depending on whether the descriptor was a data-in or data-out descriptor, and shall ensure that each RDMA 
operation is wholly contained within the memory segment by using the following rules: 

a) The RDMA operation’s starting virtual address shall be greater than or equal to the memory descriptor’s 
virtual address and less than the sum of the memory descriptor’s virtual address and data length; 
and 

b) The sum of the RDMA operation’s virtual address and data length shall be greater than the memory 
descriptor’s virtual address and less than or equal to the sum of the memory descriptor’s virtual 
address and data length. 

5.6.2 Data buffer descriptors 
5.6.2.1 Overview 

An SRPCMD request (see 6.8) may contain a data-out buffer descriptor, a data-in buffer descriptor, both, or 
neither, depending upon the data transfer(s) requested by the SCSI command. The format of each data buffer 
descriptor is specified by a format code value. In an SRP CMD request with both data-in and data-out buffer 
descriptors, there is no requirement that both buffer descriptors be of the same format. Some data buffer 
descriptor formats use the contents of a count field (i.e., SRP_CMD request data-out buffer descriptor 
count or data-in buffer descriptor count) to further describe the data buffer descriptor format. Table 2 
defines data buffer descriptor format code values. 


Table 2 - Data buffer descriptor formats 


Data buffer descriptor format code 

Reference 

format code 
value 3 

buffer descriptor 
length (bytes) 0 

NO DATA BUFFER DESCRIPTOR PRESENT 

5.6.2.3 

Oh 

0 

DIRECT DATA BUFFER DESCRIPTOR 

5.6.2.4 

1h 

16 

INDIRECT DATA BUFFER DESCRIPTOR 

5.6.2.5 

2h 

20+16*count b 

3 The format code value for a data-out buffer descriptor is specified by the data-out buffer 
descriptor format field of an SRP CMD request (see 6.8). The format code value for a data-in 
buffer descriptor is specified by the data-in buffer descriptor format field of an SRP_CMD 
request (see 6.8). 

b The count field for a data-out buffer descriptor is the data-out buffer descriptor count field of 
an SRP_CMD request (see 6.8). The count field for a data-in buffer descriptor is the data-in 
buffer DESCRIPTOR count field of an SRP_CMD request (see 6.8). 

c The length of a data buffer descriptor is determined from its format code value and the contents 
of its count field. 


5.6.2.2 Supported data buffer descriptor formats 

The REQUIRED BUFFER formats field (see table 3) of the SRP_LOGIN_REQ request (see 6.2) indicates the data 
buffer descriptor formats (see table 2) that an SRP initiator port may specify in requests sent on an RDMA 
channel. An SRP initiator port shall set the required buffer formats field to indicate all data buffer descriptor 
formats that the SRP initiator port may specify in SRP CMD requests (see 6.8) sent on that RDMA channel. An 
SRP initiator port shall not issue an SRP CMD request (see 6.8) indicating a data buffer descriptor format that 
was not indicated in the required buffer formats field value for that RDMA channel. SRP target ports are not 
required to check SRP CMD requests for data buffer descriptor formats that were not indicated in the required 
buffer formats field value. If a target port does detect that an initiator has specified a descriptor format not 
indicated in the required buffer formats field, the target port shall send an SRP_T_LOGOUT request (see 
6.6) with the reason code UNSUPPORTED FORMAT CODE VALUE SPECIFIED IN DATA-OUT BUFFER 
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DESCRIPTOR FORMAT FIELD or the reason code UNSUPPORTED FORMAT CODE VALUE SPECIFIED IN 
DATA-IN BUFFER DESCRIPTOR FORMAT FIELD, as appropriate. 

An SRP target port may accept an RDMA channel establishment request and return an SRPLOGINRSP 
response (see 6.3) if the SRP target port is able to support all of the data buffer descriptor formats indicated in 
the REQUIRED BUFFER formats field on that RDMA channel. An SRP target port shall reject the RDMA channel 
establishment request and return an SRP_LOGIN_REJ response (see 6.4) with reason ONE OR MORE 
REQUESTED DATA BUFFER DESCRIPTOR FORMATS ARE NOT SUPPORTED if the SRP target port is 
unable to support one or more of the data buffer descriptor formats indicated in the required buffer formats 
field on that RDMA channel. 

An SRP target port shall indicate the data buffer descriptor formats that it supports in the supported buffer 
formats field (see table 3) of the SRP_LOGIN_RSP response (see 6.3) or the SRP_LOGIN_REJ response 
(see 6.4). All SRP target ports shall support the DIRECT DATA BUFFER DESCRIPTOR format and may 
support other data buffer descriptor formats. 

Table 3 defines the contents of both the required buffer formats field and the supported buffer formats 
field. 


Table 3 - Supported data buffer descriptor formats 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

Reserved 

1 

Reserved idbd ddbd Reserved 


An SRP initiator port sets the idbd (indirect data buffer descriptor) bit to one in a SRP LOGIN REQ request 
(see 6.2) if it requires that the target port support the INDIRECT DATA BUFFER DESCRIPTOR format. 

The target port shall set the idbd bit to one in an SRP LOGIN RSP response (see 6.3) or in an 
SRP_LOGIN_REJ response (see 6.4) if the SRP target port supports the INDIRECT DATA BUFFER 
DESCRIPTOR format. The idbd bit shall be set to zero in an SRP LOGIN RSP response or in an 
SRPLOGINREJ response if the SRP target port does not support the INDIRECT DATA BUFFER 
DESCRIPTOR format. 

An SRP initiator port sets the ddbd (direct data buffer descriptor) bit to one in a SRP_LOGIN_REQ request (see 

6.2) if it requires that the target port support the DIRECT DATA BUFFER DESCRIPTOR format. 

The target port shall set the ddbd bit to one in an SRP LOGIN RSP response (see 6.3) or in an 
SRPLOGINREJ response (see 6.4). 

The length of requests sent by an SRP initiator port, as determined by the data buffer descriptor formats, shall 
be limited to the maximum initiator to target iu length field returned in the SRP_LOGIN_RSP response (see 

6.3) . 

5.6.2.3 No data buffer descriptor present 

The NO DATA BUFFER DESCRIPTOR PRESENT format code value specifies that the corresponding data 
buffer descriptor field is not present. The contents of the count field in the SRP_CMD request (i.e., data-out 
buffer descriptor count or data-in buffer descriptor count) are reserved. SRP target ports shall ignore 
the contents of the count field. 

5.6.2.4 Direct data buffer descriptor format 

The DIRECT DATA BUFFER DESCRIPTOR format code value specifies that the corresponding data buffer 
descriptor field is as defined in table 2 and contains a direct data buffer descriptor. The contents of the count 
field in the SRP_CMD request are reserved. SRP target ports shall ignore the contents of the count field. 
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A direct data buffer descriptor contains a single memory descriptor (see table 1). The memory descriptor 
identifies the data buffer, which is a single memory segment within a memory region’s virtual address space. If 
a direct data buffer descriptor defines a data-out buffer, the SRP target port shall issue only RDMA Read 
operations using the memory descriptor contained in the direct data buffer descriptor. If a direct data buffer 
descriptor defines a data-in buffer, the SRP target port shall issue only RDMA Write operations using the 
memory descriptor contained in the direct data buffer descriptor. The SRP target port shall use the contents of 
the data length field of the memory descriptor as the length of the data-out buffer or data-in buffer. 

5.6.2.5 Indirect data buffer descriptor format 

The INDIRECT DATA BUFFER DESCRIPTOR format code value specifies that the corresponding data buffer 
descriptor field contains an indirect data buffer descriptor (see table 2). 

An indirect data buffer is comprised of one or more memory segments. The memory segments may be 
discontiguous. The memory segments may be spread among several memory regions. The indirect data buffer 
is the concatenation of the memory segments listed in the indirect data buffer descriptor. Each memory segment 
may have any length supported by the RDMA communication service, including a length of zero bytes (see 
figure 5). 

Table 4 shows the format of an indirect data buffer descriptor. 


Table 4 - Indirect data buffer descriptor 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 



INDIRECT TABLE MEMORY DESCRIPTOR 

15 


16 

(MSB) 


TOTAL LENGTH 

19 

(LSB) 

20 



PARTIAL MEMORY DESCRIPTOR LIST 

19+16xn 


a The value ’n’ is the value contained in the data buffer descriptor’s count field. The count field for a data- 
out buffer descriptor is the data-out buffer descriptor count field of an SRP_CMD request (see 6.8). 
The count field for a data-in buffer descriptor is the data-in buffer descriptor count field of an 
SRP_CMD request (see 6.8). 


The indirect table memory descriptor is a memory descriptor (see table 1) that specifies a memory segment 
containing an indirect table. An indirect table is a list of one or more memory descriptors. The memory segments 
specified by the memory descriptors in the indirect table form the indirect data buffer. The value of the data 
length field of the indirect table memory descriptor represents the length, in bytes, of the indirect table, and 
is the number of memory descriptors in the indirect table multiplied by sixteen (the length, in bytes, of a memory 
descriptor). SRP target port behavior when the data length field of the indirect table memory descriptor 
contains any other value is vendor-specific. 

The total length field value is the sum of the data length field values of the memory descriptors in the indirect 
table. The SRP target port shall use either the total length field value or the sum of the data length field 
values as the length of the data-out buffer or data-in buffer. If the value of the total length field is not equal 
to the sum of the values of the data length fields, SRP target port behavior is vendor-specific. 
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The PARTIAL MEMORY descriptor list field is only present when the SRP_CMD information unit’s data buffer 
descriptor’s count field (i.e., data-out buffer descriptor count or data-in buffer descriptor count) 
contains a non-zero value. The partial memory descriptor list field contains a list of ’n’ memory descriptors 
that are copies of the first ’n’ memory descriptors in the indirect table. The value ’n’ is the value contained in the 
associated count field; SRP target port behavior when the partial memory descriptor list field contains any 
other value is vendor-specific. 

5.6.2.5.1 SRP target port indirect data restrictions 

An SRP target port shall issue only RDMA Read operations to the indirect table. 

If an indirect data buffer descriptor specifies a data-out buffer, the SRP target port shall issue only RDMA Read 
operations using the memory descriptors contained in the indirect table or the partial memory descriptor list 
field value. 

If an indirect data buffer descriptor specifies a data-in buffer, the SRP target port shall only issue RDMA Write 
operations using the memory descriptors contained in the indirect table or the partial memory descriptor list 
field value. 

5.6.2.5.2 Examples of indirect data buffers 

Figure 5 illustrates an indirect data buffer descriptor that does not contain a partial memory descriptor list 
field. Memory is shown containing four memory segments: the indirect table, memory segment 1, memory 
segment 2 and memory segment 3. The mapping of each memory descriptor to its memory segment has been 
shown as a single arrow. For details of this mapping see 5.6.1 and figure 4. Figure 5 does not show the memory 
regions in which the memory segments reside. All four segments may be in a single memory region, or may be 
in different memory regions. 



Figure 5 - Example indirect data buffer descriptor with no partial memory descriptor list field 

In the example shown in figure 5 the data buffer descriptor format code value is 2h and the count field contains 
zero. The indirect data buffer descriptor is 20 bytes long. The data buffer is comprised of three memory 
segments: memory segment 1, memory segment 2 and memory segment 3. A separate memory segment 
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contains the indirect table, a list of three memory descriptors specifying memory segments 1 through 3. The 
indirect table memory descriptor field value of the indirect data buffer descriptor specifies the memory 
segment containing the indirect table. The data length field of the indirect table memory descriptor field 
value contains 48 (i.e. the length of the indirect table). The total length field of the data buffer descriptor 
contains the sum of the data length field values of the memory descriptors in the indirect table (i.e. the sum of 
data length 1, data length 2 and data length 3). This sum is the total length of the data buffer. 

Figure 6 illustrates the same example as in figure 5 except with a partial memory descriptor list field. The 
data buffer, indirect table, indirect table memory descriptor field value and total length field value are all 
identical to the example in figure 5. The data buffer descriptor format code is 2h, the same as in figure 5. 
However the count field contains the value 2, indicating that the partial memory descriptor list field is present 
and contains two memory descriptors. Those two memory descriptors are copies of the first two memory 
descriptors in the indirect table. The third memory descriptor is only present in the indirect table. The indirect 
data buffer descriptor is 52 bytes long. 



Count field contains 2. 

Data buffer descriptor length is 52 bytes. 

Figure 6 - Example indirect data buffer descriptor with a partial memory descriptor list field 
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6 SRP Information Units 

6.1 Summary 

The information units used by SRP and their characteristics are shown in table 5, table 6, table 7 and table 8. 
All SRP initiator ports shall support sending the information units listed in table 5 and table 8, and shall support 
receiving the information units listed in table 6 and table 7. 

All SRP target ports shall support sending the information units listed in table 6 and table 7, and shall support 
receiving the information units listed in table 5 and table 8. 


Table 5 - SRP requests sent from SRP initiator ports to SRP target ports 


Information unit 

Reference 

type value 

Length (bytes) 

Description 

SRP_LOGIN_REQ 

6.2 

OOh 

64 

Login request 

SRP_TSK_MGMT 

6.7 

Olh 

64 

SCSI task management function 

SRPCMD 

6.8 

02h 

48 minimum 

SCSI command 

SRP_l_LOGOUT 

6.5 

03h 

16 

SRP initiator port logout notification 


Table 6 - SRP responses sent from SRP target ports to SRP initiator ports 


Information unit 

Reference 

type value 

Length (bytes) 

Description 

SRPLOGINRSP 

6.3 

COh 

52 

Login successful response 

SRPRSP 

6.9 

Clh 

36 a minimum 

SCSI status or service response 

SRP_LOGIN_REJ 

6.4 

C2h 

32 

Login failure response 

a 36 bytes is not sufficient to return any sense data. 


Table 7 - SRP requests sent from SRP target ports to SRP initiator ports 


Information unit 

Reference 

type value 

Length (bytes) 

Description 

SRPTLOGOUT 

6.6 

80h 

16 

SRP target port logout 

SRPCREDREQ 

6.10 

81h 

52 

SRP target port credit adjustment 
request 

SRP_AER_REQ 

6.12 

82h 


Obsolete 


Table 8 - SRP responses sent from SRP initiator ports to SRP target ports 


Information unit 

Reference 

type value 

Length (bytes) 

Description 

SRP_CRED_RSP 

6.11 

41h 

64 

Response to SRP target port credit 
adjustment request 

SRP_AER_RSP 

6.13 

42h 


Obselete 
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Byte 0 of each SRP information unit contains a type code. The type code value uniquely identifies the 
information unit and its format. The length of an information unit is indicated by its type code and selected fields 
within the information unit. If an SRP target port receives an SRP information unit with an invalid type code, or 
whose length is incorrect for the information unit’s type code, the SRP target port shall send an 
SRP_T_LOGOUT request (see 6.6) and disconnect the RDMA channel. 

Bytes 8 through 15 of each information unit contain a tag value, which provides a mechanism for matching SRP 
requests with their corresponding SRP responses. Each SRP request information unit (see table 5 and table 7) 
shall contain a tag value that is unique among all the outstanding SRP requests from a particular initiator port 
or target port. Each SRP response shall contain a copy of the TAG value from the corresponding SRP request. 
Responders are not required to check whether the tag values of outstanding SRP requests are unique; if tag 
values are not unique, responder behavior is unpredictable. 
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6.2 SRP_LOGIN_REQ request 

2 

An SRP_LOGIN_REQ request (see table 9) conveys SRP login parameters from an SRP initiator port to an SRP 
target port. The SRP_LOGIN_REQ request shall be sent as login data during RDMA channel establishment. 

5 
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The TAG field is defined in 6.1. 

The requested maximum initiator to target iu length field specifies the maximum length in bytes of any 
information unit that the SRP initiator port sends on this RDMA channel. This value shall be greater than 63, and 
shall include the length of any first burst data. 

The REQUIRED BUFFER formats field is defined in 5.6.2.2. 

46 

The FirstBurst bit indicates whether the initiator is requesting that the target port support first burst data. If 
FirstBurst is set to one, the initator port is requesting that the target port accept first burst data within the 
SRP CMD request information unit (see 6.8), beginning at the offset specified by First Burst Data Offset. 

50 


Table 9 - SRPLOGINREQ request 


TYPE (00h) 
Reserved 


REQUESTED MAXIMUM INITIATOR TO TARGET IU LENGTH 


REQUIRED BUFFER FORMATS 


First- Obsolete 


CRSOLNT LOSOLNT 


MULTI-CHANNEL ACTION 


First Burst Data Offset 


INITIATOR PORT IDENTIFIER 


TARGET PORT IDENTIFIER 


Page 3 


Working Draft 


SCSI RDMA Protocol-2 (SRP-2) 
Printed Monday, July 7, 2003 at 18:14:29 































































1 

2 

3 

5 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 


7 July 2003 


T10/1524-D revision 0 


Th e asynchronous e v e nt so li c i t e d not i f i cat i on b i t (AESOLNT) sp e c i f ie s wh e th e r an SRP_AER_REQ r e qu e st 

shou l d us e norma l or so li c i t e d m e ssag e r e c e pt i on not i f i cat i on. Th i s b i t sha ll b e s e t to on e to r e qu e st so li c i t e d 

not i f i cat i on, or s e t to z e ro to r e qu e st norma l not i f i cat i on. S ee 6.12. 

The obsolete bit in byte 26 was formerly the asynchronous event solicited notification (aesolnt) bit. | 

The credit request solicited notification bit (crsolnt) specifies whether an SRP_CRED_REQ request should 
use normal or solicited message reception notification. This bit shall be set to one to request solicited 
notification, or set to zero to request normal notification. (See 6.10) 

The logout solicited notification bit (LOSOLNT) specifies whether an SRP_T_LOGOUT request should use normal 
or solicited message reception notification. This bit shall be set to one to request solicited notification, or set to 
zero to request normal notification. (See 6.6) 

The multi-channel action field (see table 10) indicates how an SRP target port handles existing RDMA 
channels associated with the same l_T nexus. 


Table 10 - multi-channel action code values 


MULTI-CHANNEL ACTION 

Description 

00b 

Single RDMA channel operation (see 5.1.2) 

01b 

Multiple independent RDMA channel operation (see 5.1.3) 

10b -11b 

Reserved 


The initiator port identifier field and the target port identifier field specify the l_T nexus that shall be 
associated with this RDMA channel. 
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6.3 SRP_LOGIN_RSP response 

An SRP_LOGIN_RSP response (see table 11) indicates successful RDMA channel establishment and conveys 
SRP login parameters from an SRP target port to an SRP initiator port. 

be sent as acceptance data during RDMA channel establishment (see XX). 


Table 11 - SRP_LOGIN_RSP response 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

TYPE (C0h) 

1 


2 

Reserved 

3 


4 

(MSB) 


REQUEST LIMIT DELTA 

7 

(LSB) 

8 

(MSB) 


TAG 

15 

(LSB) 

16 

(MSB) 


MAXIMUM INITIATOR TO TARGET IU LENGTH 

19 

(LSB) 

20 

(MSB) 


MAXIMUM TARGET TO INITIATOR IU LENGTH 

23 

(LSB) 

24 


25 


26 

Reserved solntsup Reserved multi-channel result 

27 

Reserved 

28 



Reserved 

51 



The request limit delta field is defined in 5.5. 

The tag field shall contain the same value as the tag field in the SRP_LOGIN_REQ request (see 6.2). 
maximum initiator to target iu length specifies the maximum length in bytes of any information unit that the 
SRP target port is able to receive on this RDMA channel. This value shall be 64 or larger and greater than or 
equal to the value of requested maximum initiator to target iu length specified in the SRP_LOGIN_REQ 
request (see 6.2). The SRP initiator port shall not send any information unit on this RDMA channel longer than 
this value. 

maximum target to initiator iu length specifies the maximum length in bytes of any information unit that the 
SRP target port may send on this RDMA channel. This value shall be 52 or larger. The SRP target port shall not 
send any information unit on this RDMA channel longer than this value. 

The supported buffer formats field is defined in 5.6.2.2. 
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The multi-channel result field (see table 12) indicates how the SRP target port treated existing RDMA 
channels associated with the same l_T nexus. 

3 

Table 12 - multi-channel result code values 


MULTI-CHANNEL RESULT 

Description 

00b 

No existing RDMA channels were associated with the same l_T nexus. 

01b 

One or more existing RDMA channels were terminated. 

10b 

One or more existing RDMA channels continue to operate independently. 

11b 

Reserved 


13 

The solicited notification supported bit (SOLNTSUP) indicates whether the SRP target port supports solicited 
message reception notification for messages sent from the SRP target port to an SRP initiator port ((see XX)). 
If the SOLNTSUP bit is one, the SRP target port supports solicited message reception notification. If the 
SOLNTSUP bit is zero, the SRP target port only supports normal message reception notification. 
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6.4 SRP_LOGIN_REJ response 

An SRP_LOGIN_REJ response (see table 13) indicates that an RDMA channel could not be established. 

SRPJ_OGIN_REJ response shall be sent as rejection data (see XX). 


Table 13 - SRP_LOGIN_REJ response 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

TYPE (C2h) 

1 


2 

Reserved 

3 


4 

(MSB) 


REASON 

7 

(LSB) 

8 

(MSB) 


TAG 

15 

(LSB) 

16 



Reserved 

23 


24 


25 


26 



Reserved 

31 



The reason field indicates the reason that the RDMA channel could not be established. This field is defined in 
table 14. 
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Table 14 - SRP_LOGIN_REJ response reason codes 


REASON code 

Description 

0000 OOOOh - 
0000 FFFFh 

Reserved 

0001 OOOOh 

Unable to establish RDMA channel, no reason specified 

0001 0001h 

Insufficient RDMA channel resources 

0001 0002h 

REQUESTED MAXIMUM INITIATOR TO TARGET IU LENGTH value too large 

0001 0003h 

Unable to associate RDMA channel with specified l_T nexus 

0001 0004h 

One or more requested data buffer descriptor formats are not supported 

0001 0005h 

SRP target port does not support multiple RDMA channels per l_T nexus 

0001 0006h 

RDMA channel limit reached for this initiator 

0001 0007h - 
FFFF FFFFh 

Reserved 


The tag field shall contain the same value as the tag field in the SRPLOGINREQ request (see 6.2). 
The SUPPORTED BUFFER formats field is defined in 5.6.2.2. 
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6.5 SRP_l_LOGOUT request 

An SRP_l_LOGOUT request (see table 15) is sent by an SRP initiator port to notify the SRP target port that the 
SRP initiator port is disconnecting the RDMA channel. An SRP_l_LOGOUT request shall be sent as a 16-byte 
message with normal message reception notification ((see XX)). 


Table 15 - SRP_l_LOGOUT request 



The tag field is defined in 6.1. 

After sending an SRPI _LOGOUT request, an SRP initiator port shall wait for the RDMA communication service 
status indication (see XX), then request that the RDMA channel be disconnected and perform the actions 
specified in 5.1.4. 

Upon receiving an SRP I LOGOUT request an SRP target port shall perform the actions specified in 5.1.4. The 
SRP target port shall not send an SRP response to an SRPILOGOUT request. 
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6.6 SRP_T_LOGOUT request 

An SRP_T_LOGOUT request (see table 16) is sent by a SRP target port to notify the SRP initiator port that the 
SRP target port is disconnecting the RDMA channel. An SRP_T_LOGOUT request shall be sent as a 16-byte 
message. 


Table 16 - SRP_T_LOGOUT request 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

TYPE (80h) 

1 

Reserved solnt 

2 


3 


4 

(MSB) 


REASON 

7 

(LSB) 

8 

(MSB) 


TAG 

15 

(LSB) 


The solicited notification (SOLNT) bit indicates whether the SRP initiator port specified normal or solicited 
message reception notification for SRP_T_LOGOUT requests during login (see 6.2). The SOLNT bit shall 
contain the value that was specified in the LOSOLNT bit of the SRP_LOGIN_REQ request. 

If the solicited notification (SOLNT) bit is one and the SRP target port supports solicited message reception 
notification (see 6.3), the SRP target port shall send the SRP T LOGOUT response with solicited message 
reception notification (see (see XX)). If the solnt bit is zero, the SRP target port should send the 
SRP_T_LOGOUT response with normal message reception notification. An SRP initiator port shall not validate 
the SOLNT bit against whether an SRP_RSP response was actually received with normal or solicited message 
reception notification. 

The reason field indicates the reason for disconnecting the RDMA channel. This field is defined in table 17 
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Table 17 - SRP_T_LOGOUT request reason codes 


REASON code 

Description 

0000 OOOOh 

No reason specified 

0000 0001 h 

Inactive RDMA channel (reclaiming resources) 

0000 0002h 

Invalid information unit type code received by SRP target port 

0000 0003h 

SRP initator port sent response 3 with no corresponding SRP target port request 13 outstand¬ 
ing 

0000 0004h 

RDMA channel disconnected due to multi-channel action code in new SRP_LOGIN_REQ 

0000 0005h 

Reserved 

0000 0006h 

Unsupported format code value specified in data-out buffer descriptor format field 

0000 0007h 

Unsupported format code value specified in data-in buffer descriptor format field 

0000 0008h 

Invalid length for IU type 

0000 0005h 
FFFFFFFFh 

Reserved 

a See table 8. 

b See table 7. 


The tag field is defined in 6.1. 

After sending an SRP_T_LOGOUT request, an SRP target port shall wait for the RDMA communication service 
status indication (see XX), then request that the RDMA channel be disconnected and perform the actions 
specified in 5.1.4. 

Upon receiving an SRP_T_LOGOUT request an SRP initiator port shall perform the actions specified in 5.1.4. 
The SRP initiator port shall not send an SRP response to an SRP_T_LOGOUT request. 
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6.7 SRP_TSK_MGMT request 

An SRP_TSK_MGMT request conveys a SCSI task management request (table 18). An SRP_TSK_MGMT 
request shall be sent with normal message reception notification (see XX). 


Table 18 - SRP TSK MGMT request 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

TYPE (01 h) 

1 

Reserved ucsolnt scsolnt Reserved 


Pc-cr" 1 

7 


8 

(MSB) 


TAG 

15 

(LSB) 

16 



Reserved 

19 


20 

(MSB) 


LOGICAL UNIT NUMBER 

27 

(LSB) 

28 

Reserved 

29 

Reserved 

30 

TASK MANAGEMENT FUNCTION 

31 

Reserved 

32 

(MSB) 


TAG OF TASK TO BE MANAGED 

39 

(LSB) 

40 



Reserved 

47 



The unsuccessful completion solicited notification bit (UCSOLNT) specifies whether an SRP_RSP response 
reporting unsuccessful completion of the task management request should use normal or solicited message 
reception notification. This bit shall be set to one to request solicited notification, or set to zero to request normal 
notification. See 6.9. 

The successful completion solicited notification bit (SCSOLNT) specifies whether an SRP_RSP response 
reporting successful completion of the task management request should use normal or solicited message 
reception notification. This bit shall be set to one to request solicited notification, or set to zero to request normal 
notification. See 6.9. 

The tag field is defined in 6.1. 

The logical unit number field identifies the logical unit to which the task management request is directed. The 
structure of the logical unit number field shall be as defined in the SCSI Architecture Model-2 standard. This 
field is reserved if the task management request is not directed to either an l_T_L or l_T_L_Q nexus. 


Working Draft 

SCSI RDMA Protocol-2 (SRP-2) 

Printed Monday, July 7, 2003 at 18:14:33 


Page 12 






T10/1524-D revision 0 


7 July 2003 


The TASK management function field is defined in table 19. If task management function contains a reserved 
or restricted value, the task manager shall return an SRP_RSP response (see 6.9) containing GOOD status. 

The rsp_code field shall be set to TASK MANAGEMENT FUNCTION NOT SUPPORTED. 

4 

Table 19 - task management function codes 

6 


8 

9 

10 
11 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

If task management flags specifies that an ABORT TASK function shall be performed, the tag of task to be 
managed field specifies the tag value from the SRP CMD request (see 6.8) that contained the task to be 
aborted. The tag of task to be managed field shall be ignored if task management flags specifies any other 
function. 

31 

32 

33 

34 

35 

36 
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Code 

Description 

OOh 

Reserved 

Olh 

The task manager shall perform an ABORT TASK function (see SAM-2). 

02h 

The task manager shall perform an ABORT TASK SET function (see SAM-2). 

03h 

Reserved 

04h 

The task manager shall perform a CLEAR TASK SET function (see SAM-2). 

05h-07h 

Reserved 

08h 

The task manager shall perform a LOGICAL UNIT RESET function (see SAM-2). 

09h-1Fh 

Reserved 

20h 

Restricted. 

21h-3Fh 

Reserved 

40h 

The task manager shall perform a CLEAR ACA function (see SAM-2). 

41h-FFh 

Reserved 
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6.8 SRP_CMD request 

An SRP_CMD request conveys a SCSI command (see table 20). 


Table 20 - SRP CMD request 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

TYPE (02h) 

1 

Reserved ucsolnt scsolnt Reserved 


Pc-cr J 

4 


5 

DATA-OUT BUFFER DESCRIPTOR FORMAT DATA-IN BUFFER DESCRIPTOR FORMAT 

6 

DATA-OUT BUFFER DESCRIPTOR COUNT 

7 

DATA-IN BUFFER DESCRIPTOR COUNT 

8 

(MSB) 


TAG 

15 

(LSB) 

16 



Reserved 

19 


20 

(MSB) 


LOGICAL UNIT NUMBER 

27 

(LSB) 

28 

Reserved 

29 

Reserved task attribute 

30 

Reserved 

31 

additional cdb length = n Reserved 

32 



CDB 

47 


48 



ADDITIONAL CDB 

47+4xn 


48+4xn 



DATA-OUT BUFFER DESCRIPTOR 

47+4xn+do a 


48+4xn+do a 



DATA-IN BUFFER DESCRIPTOR 

47+4xn+do+di b 


a The value ’do’ is the length in bytes of the data-out buffer descriptor field, determined from the format 
code value contained in the data-out buffer descriptor format field and the count value contained in the 
DATA-OUT BUFFER DESCRIPTOR COUNT field (see 5.6.2). 

b The value ’di’ is the length in bytes of the data-in buffer descriptor field, determined from the format code 
value contained in the data-in buffer descriptor format field and the count value contained in the data-in 
buffer descriptor count field (see 5.6.2). 
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An SRP_CMD request shall be sent as a message whose length is 48 bytes plus the lengths of the additional 
cdb, data-out buffer descriptor, and data-in buffer descriptor fields. An SRP_CMD request shall be sent 
with normal message reception notification (see XX). 

The unsuccessful completion solicited notification bit (ucsolnt) specifies whether an SRP_RSP response 
reporting unsuccessful completion of the task management request should use normal or solicited message 
reception notification. This bit shall be set to one to request solicited notification, or set to zero to request normal 
notification (see 6.9). 

The successful completion solicited notification bit (scsolnt) specifies whether an SRP RSP response 
reporting successful completion of the task management request should use normal or solicited message 
reception notification. This bit shall be set to one to request solicited notification, or set to zero to request normal 
notification (see 6.9). 

The data-out buffer descriptor format field specifies the format of the data-out buffer descriptor field 
(see 5.6.2). 

The data-in buffer descriptor format field specifies the format of the data-in buffer descriptor field (see 
5.6.2). 

The data-out buffer descriptor count field provides additional information to specify the format of the data- 
out buffer descriptor field (see 5.6.2). 

The data-in buffer descriptor count field provides additional information to specify the format of the data-in 
buffer DESCRIPTOR field (see 5.6.2). 

The tag field is defined in 6.1. 

The logical unit number field specifies the address of the logical unit of the l_T_L_Q nexus for the current task. 
The structure of the logical unit number field shall be as defined in the SCSI Architecture Model-2 standard. If 
the addressed logical unit does not exist, the task manager shall follow the SCSI rules for selection of invalid 
logical units as defined in the SCSI Primary Commands-2 standard. 

The task attribute field is defined in table 21. 


Table 21 - task attribute 


Codes 

Description 

000b 

Requests that the task be managed according to the rules for a simple task 
attribute. (See SAM-2) 

001b 

Requests that the task be managed according to the rules for a head of queue 
task attribute. (See SAM-2) 

010b 

Requests that the task be managed according to the rules for an ordered 
attribute. (See SAM-2) 

011b 

Reserved 

100b 

Requests that the task be managed according to the rules for an automatic 
contingent allegiance task attribute. (See SAM-2) 

101b-111b 

Reserved 


The additional cdb length field contains the length, in four-byte words, of the additional cdb field. 

The cdb and additional cdb fields together contain the CDB to be interpreted by the addressed logical unit. Any 
bytes between the end of the CDB and the end of the two fields shall be reserved. 
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The contents of the CDB shall be as defined in the SCSI command standards. 

The data-out buffer descriptor field specifies the buffer that shall be used for data-out transfers (see 5.6.2). 
The data-in buffer descriptor field specifies the buffer that shall be used for data-in transfers (see 5.6.2). 
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6.9 SRP_RSP response 

An SRP_RSP response (see table 22) conveys an SRP response to an SRP_TSK_MGMT request (see 6.7) or 
an SRP_CMD request (see 6.8) received by a SRP target port. SRP_RSP responses that contain neither 
response data nor sense data shall be sent as a 36 byte message. SRP_RSP responses that contain either 
response data or sense data shall be sent as the minimum length message containing those fields. 


Table 22 - SRP_RSP response 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

TYPE (Clh) 

1 

Reserved solnt 

2 

Pc~ C r ' 

3 


4 

(MSB) 


REQUEST LIMIT DELTA 

7 

(LSB) 

8 

(MSB) 


TAG 

15 

(LSB) 

16 

Pc~ C r J 

17 


18 

Reserved diunder diover dounder doover snsvalid rspvalid 

19 

STATUS 

20 

(MSB) 


DATA-OUT RESIDUAL COUNT 

23 

(LSB) 

24 

(MSB) 


DATA-IN RESIDUAL COUNT 

27 

(LSB) 

28 

(MSB) 


SENSE DATA LIST LENGTH = n 

31 

(LSB) 

32 

(MSB) 


RESPONSE DATA LIST LENGTH = m 

35 

(LSB) 

36 

(MSB) 


response data (m bytes long) 

35+m 

(LSB) 

36+m 

(MSB) 


sense data (n bytes long) 

35+m+n 

(LSB) 


The solicited notification (SOLNT) bit indicates whether the SRP initiator port specified normal or solicited 
message reception notification for this response. If the status field is non-zero or if the rsp_code field is present 
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and non-zero, then the solnt bit shall contain the value that was specified in the ucsolnt bit of the 
corresponding SRP_CMD or SRP_TSK_MGMT request; otherwise, the solnt bit shall contain the value that 
was specified in the scsoLNTbit of the corresponding SRP CMD or SRP_TSK_MGMT request. 

If the solicited notification (solnt) bit is one and the SRP target port supports solicited message reception 
notification (see 6.3), the SRP target port shall send the SRP_RSP response with solicited message reception 
notification (see 4.3); otherwise,the SRP target port should send the SRP_RSP response with normal message 
reception notification. An SRP initiator port shall not validate the solnt bit against whether an SRP_RSP 
response was actually received with normal or solicited message reception notification. 

The request limit delta field is defined in 5.5. 

The tag field shall contain the same value as the tag field in the SRP_TSK_MGMT request (see 6.7) or 
SRP_CMD request (see 6.8) for which this SRP_RSP response is a response. 

dounder, when set to one, indicates that the data-out residual count field is valid and contains the count of 
data bytes that were expected to be transferred from the data-out buffer, but were not transferred. The 
application client should examine the data-out residual count field in the context of the command to 
determine whether or not an error condition occurred. 

doover, when set to one, indicates that the data-out residual count field is valid and contains the count of 
data bytes that could not be transferred from the data-out buffer because the length of the data-out buffer was 
not sufficient. The application client should examine the data-out residual count field in the context of the 
command to determine whether or not an error condition occurred. 

dounder and doover, when both set to zero, indicate that the data-out residual count field is not valid; the 
SRP initiator port shall ignore its contents. The SRP target port shall not set both dounder and doover to one. 
diunder, when set to one, indicates that the data-in residual count field is valid and contains the count of data 
bytes that were expected to be transferred to the data-in buffer, but were not transferred. The application client 
should examine the data-in residual count field in the context of the command to determine whether or not an 
error condition occurred. 

diover, when set to one, indicates that the data-in residual count field is valid and contains the count of data 
bytes that could not be transferred to the data-in buffer because the length of the data-in buffer was not 
sufficient. The application client should examine the data-in residual count field in the context of the command 
to determine whether or not an error condition occurred. 

diunder and diover, when both set to zero, indicate that the data-in residual count field is not valid; the SRP 
initiator port shall ignore its contents. The SRP target port shall not set both diunder and diover to one. 
snsvalid, when set to zero, indicates that the contents of the sense data list length field shall be ignored and 
that the sense data field is not present, snsvalid, when set to one, indicates that the contents of the sense data 
list length field specify the number of bytes in the sense data field. 

If sense data is provided, snsvalid shall be set to one and the sense data list length field shall specify the 
number of bytes in the sense data field. 

If returning all the sense data provided would cause the SRP_RSP response to be longer than the value of the 
MAXIMUM TARGET to initiator iu length field indicated in the SRP_LOGIN_RSP response (see 6.3) when the 
RDMA channel was established, the SRP target port shall return an SRP_RSP response whose length is the 
value from the maximum target to initiator iu length field. The sense data field shall be truncated as needed 
to achieve this length, sense data list length shall contain the length of the truncated sense data field. 

If no sense data is provided, snsvalid shall be set to zero. The SRP initiator port shall ignore the sense data 
list length field and shall assume a length of zero. 
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rspvalid set to zero indicates that the contents of the response data list length field shall be ignored and the 
response data field is not present, rspvalid set to one indicates that the contents of the response data list 
length field specify the number of bytes in the response data field, rspvalid set to one also indicates that the 
contents of the status field shall be ignored by the SRP initiator port. 

If response data is provided, rspvalid shall be set to one and the response data list length field shall specify 
the number of bytes in the response data field (see table 23). The response data list length field shall 
contain the value four. Other lengths are reserved for future standardization. 

8 

If no response data is provided, rspvalid shall be set to zero. The SRP initiator port shall ignore the response 
data list length field and shall assume a length of zero. 

Response data shall be provided in any SRP_RSP response that is sent in response to an SRP_TSK_MGMT 
request (see 6.7). The information in the rsp_code field (see table 24) shall indicate the completion status of 
the task management function. 

Response data shall not be provided in any SRP RSP response that returns a non-zero status code in the 
STATUS field. 

16 

The status field contains the status of a task that completes. See the SAM-2 standard for a list of status codes. 

If either dounder or doover is set to one, the data-out residual count field contains a count of the number 
of residual data bytes that were not transferred from the data-out buffer for this SCSI command. Upon 
successful completion of an SRP I/O operation, the residual data-out byte count is normally zero and the data- 
out residual count value is not valid. Some commands may have a non-zero residual data-out byte count that 
is not an error. SRP target ports are not required to check the data-out length implied by the contents of the CDB 
for overrun or underrun before processing a SCSI command. 

24 

If dounder is set to one and a transfer that did not fill the entire data-out buffer was performed, the value of 
DATA-OUT residual count is defined as follows: 

data-out residual count = (data-out buffer length) - (highest offset of any data-out byte transmitted + 1) 

A condition of dounder set to one may not be an error for some devices and some commands. 

If doover is set to one, the transfer was truncated because the data-out transfer required by the SCSI command 
was longer than the data-out buffer (see 5.6.2). Those bytes that could not be transferred without exceeding the 
length of the data-out buffer shall not be transferred. The data-out residual count is defined as follows: 
data-out residual count = (Transfer length required by command) - (data-out buffer length) 

34 

If doover is set to one, the termination state of the SRP I/O operation is not certain. Data may not have been 
transferred from the data-out buffer and the SCSI status byte may not provide correct command completion 
information. 

If either diunder or diover is set to one, the data-in residual count field contains a count of the number of 
residual data bytes that were not transferred to the data-in buffer for this SCSI command. Upon successful 
completion of an SRP I/O operation, the residual data-in byte count is normally zero and the data-in residual 
count value is not valid. Some commands (e.g., inquiry) may have a non-zero residual data-in byte count that 
is not an error. SRP target ports are not required to check the data-in length implied by the contents of the CDB 
for overrun or underrun before processing a SCSI command. 

If DIUNDER is set to one and a transfer that did not fill the entire data-in buffer was performed, the value of data- 
in residual count is defined as follows: 

46 

data-in residual count = (data-in buffer length) - (highest offset of any data-in byte transmitted + 1) 

A condition of diunder set to one may not be an error for some devices and some commands. 

49 

50 
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If diover is set to one, the transfer was truncated because the data-in transfer required by the SCSI command 
was longer than the data-in buffer (see 5.6.2). Those bytes that could not be transferred without exceeding the 
length of the data-in buffer shall not be transferred. The data-in residual count is defined as follows: 

data-in residual count = (Transfer length required by command) - (data-in buffer length) 

If diover is set to one, the termination state of the SRP I/O operation is not certain. Data may not have been 
transferred to the data-in buffer and the SCSI status byte may not provide correct command completion 
information. 

The DATA-OUT RESIDUAL COUNT, DATA-IN RESIDUAL COUNT, SENSE DATA LIST LENGTH, and RESPONSE DATA LIST 

length fields shall always be present in the SRP_RSP response, regardless of whether their contents are valid. 
The response data field (see table 23) contains information describing protocol failures detected during 
processing of an SRP request received by the SRP target port. The response data field shall be present if the 
SRP target port detects any of the conditions described by a non-zero rsp_code value (see table 24). 
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Table 23 - response data field 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

Reserved 

1 

Reserved 

2 

Reserved 

3 

RSP_CODE 


The rsp_code field is defined in table 24. 

Table 24 - rsp_code values 


Codes 

Description 

OOh 

TASK MANAGEMENT FUNCTION COMPLETE. 

Olh 

Reserved 

02h 

REQUEST FIELDS INVALID 

03h 

Reserved 

04 h 

TASK MANAGEMENT FUNCTION NOT SUPPORTED 

05h 

TASK MANAGEMENT FUNCTION FAILED 

06h-FFh 

Reserved 


The sense data field contains the autosense data specified by the SCSI Primary Commands-2 standard. The 
proper sense data shall be presented when the SCSI status byte of CHECK CONDITION is presented as 
specified by the SCSI Primary Commands-2 standard. If no conditions requiring the presentation of SCSI sense 
data have occurred, the sense data field shall not be included in the SRP_RSP response and the snsvalid bit 
shall be zero. SRP devices shall perform autosense. 
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6.10 SRP_CRED_REQ request 

An SRP target port may use SRP_CRED_REQ requests (see table 25) to adjust an SRP initiator port’s request 
limit value (see 5.5). An SRP_CRED_REQ request shall be sent as a 16 byte message. 


Table 25 - SRPCREDREQ request 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

TYPE (81 h) 

1 

Reserved solnt 

2 

P c_ cr i 

3 


4 

(MSB) 


REQUEST LIMIT DELTA 

7 

(LSB) 

8 

(MSB) 


TAG 

15 

(LSB) 


The solicited notification (solnt) bit indicates whether the SRP initiator port specified normal or solicited 
message reception notification during login (see 6.2) for SRP_CRED_REQ requests. The solnt bit shall contain 
the value that was specified in the CRSOLNT bit of the SRP_LOGIN_REQ request. 

If the solicited notification (solnt) bit is one and the SRP target port supports solicited message reception 
notification (see 6.3), the SRP target port shall send the SRP CRED REQ request with solicited message 
reception notification (see (see XX)); otherwise the SRP target port should send the SRP CRED REQ request 
with normal message reception notification. An SRP initiator port shall not validate the solnt bit against whether 
an SRP_CRED_REQ request was actually received with normal or solicited message reception notification. 
The request limit delta field is defined in 5.5. 

The tag field is defined in 6.1. 
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6.11 SRP_CRED_RSP response 

An SRP_CRED_RSP response (see table 26) is the response to an SRP_CRED_REQ request (see 6.10) 
received by an SRP initiator port. All SRP initiator ports shall support generating SRP_CRED_RSP responses. 
An SRP_CRED_RSP response shall be sent as a 16-byte message with normal message reception notification 
(see XX). 


Table 26 - SRP_CRED_RSP response 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

TYPE (41 h) 

1 

Pc-cr J 

7 


8 

(MSB) 


TAG 

15 

(LSB) 


18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 


The tag field shall contain the same value as the tag field in the SRP_CRED_REQ request (see 6.10) for which 
this SRP_CRED_RSP response is a response. 
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6.12 SRP_AER_REQ request 

(Removed) 

6.13 SRP_AER_RSP response 

(Removed) 
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7 SCSI mode parameters 

7.1 SCSI mode parameter overview and codes 

This subclause describes the block descriptors and the pages used with MODE SELECT and MODE SENSE 
commands that influence, control, and report the behavior of the SRP target port. All mode parameters not 
defined in this standard shall influence the behavior of the SCSI devices as specified in the appropriate 
command set document. The mode pages are addressed to the device server of a logical unit. The mode 
pages associated with this protocol are listed in table 27. 


Table 27 - SRP mode page codes 


Page code 

Description 

Subclause 

02h 

Disconnect-reconnect page 

7.2 

18h 

Protocol specific LUN page 

7.3 

19h 

Protocol specific port page 

7.4 


7.2 Disconnect-reconnect mode page 

The disconnect-reconnect page (see table 28) provides the application client the means to tune the 
performance of the service delivery subsystem. This subclause defines the fields in the disconnect-reconnect 
mode page of the MODE SENSE or MODE SELECT command that are used by SRP target ports. 


Table 28 - Disconnect-reconnect mode page 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

PS 

Reserved 

PAGE CODE (02h) 

1 

PAGE LENGTH(0EH) 

2 

BUFFER FULL RATIO 

3 

BUFFER EMPTY RATIO 

4 


BUS INACTIVITY LIMIT 


5 



6 


PHYSICAL DISCONNECT TIME LIMIT 


7 



8 


CONNECT TIME LIMIT 


9 



10 

(MSB) 

MAXIMUM BURST SIZE 


11 


(LSB) 

12 

EMDP 

13 

Reserved 

14 

(MSB) 

FIRST BURST SIZE 


15 


(LSB) 


The application client passes the fields used to control the SRP target port to a device server by means of a 
MODE SELECT command. The device server then communicates the field values to the SRP target port. The 
field values are communicated from the device server to the SRP target port in a vendor-specific manner. 
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7.2.1 Valid fields 

SRP devices shall use only the Disconnect-Reconnect page fields listed in this subciause. If any other fields 
(see 7.2.2) within the disconnect-reconnect page of the MODE SELECT command contain a non-zero value, 
the device server shall return CHECK CONDITION status for that MODE SELECT command. The device 
server shall set the sense key to ILLEGAL REGUEST and set the additional sense code to ILLEGAL FIELD IN 
PARAMETER LIST. 

The maximum burst size field indicates the maximum size of an RDMA Read or RDMA Write operation that 
the device server shall perform. This value is expressed in increments of 512 bytes (e.g., a value of one 
means 512 bytes, two means 1024 bytes, etc.). The device server may round this value down as defined in 
SPC-2. A value of zero indicates that the maximum transfer size is limited only to that of the underlying 
interconnect. The value zero shall be implemented by all SRP devices. The application client and device 
server may use the value of this parameter to adjust internal maximum buffering requirements. A router 
between an SRP device and another protocol device (e.g. FCP) may intercept and adjust this value to reflect 
its own maximum buffering capabilities. 

The enable modify data pointers (emdp) bit indicates whether the SRP target port may use the random 
buffer access capability to order RDMA requests for a single SCSI command. If the emdp bit is set to zero, the 
SRP target port shall generate RDMA requests with continuously increasing addresses for a single SCSI 
command. If the emdp bit is set to one, the SRP target port may issue RDMAs for a single SCSI command in 
any order.The emdp function shall be implemented by SRP devices. 

The first burst size field indicates the maximum amount of data-out that the target port supports receiving 
along with the command (i.e., the first burst). This value is expressed in increments of 512 bytes; a value of 
one means 512 bytes, two means 1024 bytes, etc. A value of zero indicates that the target does not support 
first burst functionality. The maximum first burst size value for a connection is set at login (see 6.2). This value 
shall not be settable via the mode select command. 

7.2.2 Invalid fields 

I 


The BUFFER FULL RATIO field, BUFFER EMPTY RATIO field, BUS INACTIVITY LIMIT field, PHYSICAL DISCONNECT TIME 
LIMIT field, CONNECT TIME LIMIT, FAIR ARBITRATION field, DISCONNECT IMMEDIATE (DIMM) bit, and DATA TRANSFER 

disconnect control (dtdc) field and f i rst b urst f iel d shall be set to zero by SRP initiator and SRP target 
ports. 


7.3 Protocol specific LUN page 

The Protocol Specific LUN page shall not be implemented by SRP target ports. 

7.4 Protocol specific port page 

The Protocol Specific Port page shall not be implemented by SRP target ports. 


2 

3 

5 

6 


10 

12 

13 

15 

16 


20 


23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 


50 


Page 2 


Working Draft 


SCSI RDMA Protocol-2 (SRP-2) 
Printed Monday, July 7, 2003 at 18:14:39 



7 July 2003 


T10/1524-D revision 0 


Annex A 

(normative) 


srp interface protocol and services 
A.1 Service interface protocol 

This standard describes a SCSI device’s behavior in terms of functional levels, service interfaces between levels 
and peer-to-peer protocols. For a full description of the model used in this standard see SAM-2. Figure A.1 
shows the model as it appears from the point of view of this standard. 



SCSI Application 


SCSI 

Protocol 

SCSI 

Application 

◄.► 

Device 

Client 


Server 


SCSI RDMA Protocol Service Interface 


|_ RDMA Communication Services _| 

Figure A.1 - SRP reference model 

Services between service levels are either four-step confirmed services or two-step confirmed services. A four- 
step confirmed service consists of a service request, indication, response, and confirmation. A two-step 
confirmed service consists of a service request and confirmation. 
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Figure A.2 shows the service and protocol interactions for a four-step confirmed service. 



Figure A.2 - Model for a four-step confirmed service 

The SCSI RDMA four-step confirmed service protocol consists of the following interactions: 

1. A request to the client consumer to invoke a service; 

2. An indication from the server consumer notifying the SCSI device server or task manager of an event; 

3. A response from the SCSI device server or task manager in reply to an indication; 

4. A confirmation from the client consumer upon service completion. 

Only application clients shall request a four-step confirmed service be invoked. 

Figure A.3 shows the service and protocol interactions for a two-step confirmed service. 



Figure A.3 - Model for a two-step confirmed service 

The SCSI RDMA two-step confirmed service interface consists of the following interactions: 
1. A request to the server consumer to invoke a service; 
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2. A confirmation from the server consumer upon service completion. 

Only SCSI device servers shall request a two-step confirmed service be invoked. 

A.2 SRP services 

SRP provides services to enable an application client to request and manage tasks (see SAM-2) and to enable 
a device server to receive commands and move data to and from an application client. The SRP services are 
described in terms of the services the SRP initiator port and SRP target port provide. 

A.3 SAM-2 object mapping 

See table A.1 for the SRP objects corresponding to SAM-2 identifiers and names. 


12 

Table A.1 

- SAM-2 object mapping 

13 

SAM-2 object 

SRP object 

14 

initiator port identifier 

initiator port identifier 

15 

initiator port name 

16 

target port identifier 
target port name 

target port identifier 


18 


19 

20 
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22 

23 
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25 
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28 

29 
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31 

32 

33 

34 
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37 

38 

39 
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42 

43 


A.4 Procedure objects 

See table A.2 for a list of the procedure objects used within this standard, the name of the standard where the 
objects are defined, the standard where the binary contents of the objects are defined, and the routing of the 
objects. The routing shows: 

a) the source of the object 

b) the final destination of the object, and 

c) the routing of the object. 
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Table A.2 - Procedure objects 


Procedure object 

Standard where object 
format is defined 

Object routing 

application client buffer offset 

SAM-2 

DS -► targ-^ init 

data-out buffer size 

SAM-2 

AC -► init 

data-in buffer size 

SAM-2 

AC -► init 

command descriptor block 

SAM-2/cmd a 

AC -► init -► targ -► DS 

data-in buffer 

cmd b 

DS -► targ-^ init -► AC 

data-out buffer 

cmd b 

AC -► init -► targ -► DS 

device server buffer 

cmd b 

DS -► targ-^ init 

l_T_L_x nexus 

this standard 

AC -► init -► targ -► DS 
or AC -► init -► targ -► TM 
or DS -► targ-^ init 

request byte count 

SAM-2 

DS -► targ 

service response 

this standard 0 

DS -► targ-^ init -► AC 
or targ -► DS 

autosense request 

SAM-2 

AC -► init -► targ -► DS 

sense data 

SPC-2 

DS -► targ-^ init -► AC 

status 

SAM-2 

DS -► targ-^ init -► AC 

task attribute 

this standard 

AC -► init -► targ -► DS 

Key: AC=application client, cmd=SCSI command standards, DS=device server, init=SRP 
initiator port, SAM-2=SAM-2, TM=task manager, targ=SRP target port 

a The portions not defined in SAM-2 are defined in the SCSI command standards (e.g., 
SPC-2). 

b Parameter lists are defined within one of the SCSI command standards (e.g., SPC-2). 

SCSI standards do not define non-parameter list information. 

c The SERVICE DELIVERY OR TARGET FAILURE value of the service response is not 
defined in SCSI. 


A.5 Application client SCSI command services 
A.5.1 Application client SCSI command services overview 

The SCSI command services shall be requested by the application client using a procedure call defined as: 
Execute Command (IN (l_T_L_x nexus, command descriptor block, [task attribute], [data-in buffer size], 
[data-out buffer], [data-out buffer size], autosense request), OUT ([data-in buffer], [sense data], status, 
service response)) 

A.5.2 Send SCSI command service 

The send SCSI command service is a four-step confirmed service (see figure A.2) that provides the means to 
transfer a command data block to a device server. 
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Processing the execute command procedure call for a send SCSI command service shall be composed of the 
four-step confirmed service shown in table A.3. 


Table A.3 - Processing of execute command procedure call for a send SCSI command service 


Step 

(step number) 3 

Source to 
Destination 

Protocol 
service name 

SCSI Protocol Service Interface 
procedure calls 

request (1) 

application client 
to 

client consumer 

send SCSI command 
request 

Send SCSI command (IN (l_T_L_x 
nexus, command descriptor block, [task 
attribute], [data-in buffer size], [data-out 
buffer], [data-out buffer size], autosense 
request)) 

information unit 
transfer (la) 

client consumer to 

server consumer 

SRP CMDrequestor 
SRP_TSK_MGMT 
request 

See 6.7 and 6.8 

indication (2) 

server consumer 

to 

device server 

send SCSI command 
indication 

SCSI command received (IN (l_T_L_x 
nexus, command descriptor block, [task 
attribute], autosense request)) 

If the send SCSI command requires a data transfer see A.6.2 for data-out delivery services and A.6.3 for 
data-in delivery services 

response (3) 

device server to 

server consumer 

send SCSI command 
response 

Send command complete (IN (l_T_L_x 
nexus, [sense data], status, service 
response)) 

information unit 
transfer (3a) 

server consumer 

to 

client consumer 

SRP_RSP response 

See 6.9 

confirmation (4) 

client consumer to 
application client 

send SCSI command 
confirmation 

Command complete received (IN 
(l_T_L_x nexus, [data-in buffer], [sense 
data], status, service response)) 

a See figure A.2 for step number 


A.6 Device server SCSI command services 
A.6.1 Device server SCSI command services overview 

The SCSI data buffer movement services shall be requested from the device server using a procedure call 
defined as: 

Move data buffer (IN (l_T_L_x nexus, device server buffer, application client buffer offset, request byte 
count)). 

Either data-in delivery, data-out delivery, both data-in and data-out delivery, or neither data delivery may be 
used while processing one command. If both are used, the device server shall combine the data-in and data- 
out service responses into one service response. 

A.6.2 Data-out delivery service 

The data-out delivery service is a two-step confirmed service (see figure A.3) that provides the means to transfer 
a parameter list or data from an SRP initiator port to a device server. 
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Processing the execute command procedure call for a data-out delivery service shall be composed of the two- 
step confirmed service shown in table A.4. 


Table A.4 - Processing of execute command procedure call for a data-out delivery service 


Step 

(step number) 3 

Source/Destina 

tion 

Protocol service 

name 

SCSI Protocol Service Interface 
procedure call 

request (1) 

device server to 

server consumer 

data-out delivery 
request 

Receive data-out (IN (l_T_L_x nexus, 
application client buffer offset, request 
byte count, device server buffer)) 

data-out transfer 
(la and 1b) 

server consumer 

to client 
consumer 15 

RDMA data-out 
transfer 

See (see XX). 

confirmation (2) 

server consumer 

to device server 

data-out delivery 
confirmation 

Data-out received (IN (l_T_L_x nexus)) 

a See figure A.3 for step number 

b RDMA transfers are typically performed by hardware without the intervention of the client consumer. 


A.6.3 Data-in delivery service 

The data-in delivery service is a two-step confirmed service (see figure A.3) that provides the means to transfer 
a parameter list or data from a device server to an SRP initiator port. 

Processing the execute command procedure call for a data-in delivery service shall be composed of the two- 
step confirmed service shown in table A.5. 


Table A.5 - Processing of execute command procedure call for a data-in delivery service 


Step 

(step number) 3 

Source to 
Destination 

Protocol 
service name 

SCSI Protocol Service Interface 
procedure call 

request (1) 

device server to 

server consumer 

data-in delivery 
request 

Send data-in (IN (l_T_L_x nexus, device 
server buffer, application client buffer 
offset, request byte count)) 

data-in transfer 
(la and 1b) 

server consumer 

to client 
consumer 15 

RDMA data-in 
transfer 

See (see XX). 

confirmation (2) 

server consumer 

to device server 

data-in delivery 
confirmation 

Data-In delivered (IN (l_T_L_x nexus)) 

3 See figure A.3 for step number. 

b RDMA transfers are typically performed by hardware without the intervention of the client consumer. 


A.7 Task management services 

A.7.1 Task management functions overview 

The task management services shall be requested from the application client using a procedure call defined as: 
Function name (IN (nexus), service response) 
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A.7.2 Task management functions 

This standard handles task management functions as a four-step confirmed service that provides the means to 
transfer task management functions to a task manager. 

The task management functions are defined in the SAM-2. This standard defines the actions taken by the SRP 
services to carry out the requested task management functions. 

A.7.3 ABORT TASK 

The SRP services request the SRP initiator port issue an SRP_TSK_MGMT request (see 6.7) with a task 
management flags field set to indicate an ABORT TASK function to be sent to the selected SCSI device. 

A.7.4 ABORT TASK SET 

The SRP services request the SRP initiator port issue an SRP_TSK_MGMT request (see 6.7) with a task 
management flags field set to indicate an ABORT TASK SET function to be sent to the selected SCSI device. 

A.7.5 CLEAR ACA 

The SRP services request the SRP initiator port issue an SRP_TSK_MGMT request (see 6.7) with a task 
management flags field set to indicate a CLEAR ACA function to be sent to the selected SCSI device. 

A.7.6 CLEAR TASK SET 

The SRP services request the SRP initiator port issue an SRP_TSK_MGMT request (see 6.7) with a task 
management flags field set to indicate a CLEAR TASK SET function to be sent to the selected SCSI device. 

A.7.7 LOGICAL UNIT RESET 

The SRP services request the SRP initiator port issue an SRP_TSK_MGMT request (see 6.7) with a task 
management flags field set to indicate a LOGICAL UNIT RESET function to be sent to the selected SCSI 
device. 

A.7.8 TARGET RESET 

This protocol does not support use of the TARGET RESET task management function. 

A.7.9 WAKEUP 

This protocol does not support use of the WAKEUP task management function. 
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Annex B 

(normative) 

3 

SRP for the InfiniBand™ Architecture 

B.1 Overview 

This annex specifies requirements for mapping SRP onto the InfiniBand™ Architecture, a transport that 
implements a superset of the RDMA communication service (see clause 4). See Infiniband™ Architecture 
Specification Volume 1 Release I.O.a (IBAS)fora description of the InfiniBand™ Architecture. 

B.2 Normative references 

Infiniband™ Architecture Specification Volume 1 Release I.O.a, Infiniband Trade Association 
(www.infinibandta.org). 

IETF RFC 2373, IP Version 6 Addressing Architecture. R. Hinden and S. Deering. Internet Engineering 
Task Force (www.ietf.org). 

B.3 Definitions and abbreviations 

B.3.1 Introduction to definitions and abbreviations 

The definitions in B.3.2 and the abbreviations in B.3.3 are incomplete without reference to IBAS. 

21 

B.3.2 Definitions 

B.3.2.1 IB channel adapter: A device that terminates an InfiniBand™ Architecture link and processes 
transport-level functions. 

B.3.2.2 IB channel adapter GUID: An IB GUID that uniquely identifies an IB channel adapter. 

26 

B.3.2.3 IB communication manager: The software, hardware, or combination of the two that supports the 
InfiniBand™ Architecture communication management mechanisms and protocols. 

B.3.2.4 IB consumer: An object that communicates with other IB consumers using the InfiniBand™ 
Architecture. 

31 

B.3.2.5 IB GID: A 128-bit value that conforms to the IPv6 address format. 

B.3.2.6 IB GUID: A globally unique value that identifies an InfiniBand™ Architecture device or component. 

B.3.2. 7 IB General Service Interface: An interface providing management services other than IB subnet 
management. 

B.3.2.8 IB I/O controller: The part of an IB I/O unit that provides I/O services. 

B.3.2.9 IB I/O controller GUID: An IB GUID that uniquely identifies an IB I/O controller. This value is present 
as the GUID field of the lOControllerProfile attribute. (See Table B.7) 

B.3.2.10 IB I/O unit: One or more IB I/O controllers attached to the IB fabric through a single IB channel 
adapter. 

B.3.2.11 IB LID: A port address used for directing IB packets within an IB subnet. 

B.3.2.12 IB MAD: An IB packet used to manage an InfiniBand™ Architecture network. 

TM 

B.3.2.13 IB packet: The indivisible unit of InfiniBand ""Architecture data transfer and routing, consisting of one 
or more headers, a packet payload, and one or two CRCs. 

B.3.2.14 IB port: A location on an IB channel adapter, switch, or router to which a link connects. 

B.3.2.15 IB port GUID: An IB GUID that uniquely identifies an IB port. 
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B.3.2.16 IB Queue Pair: An interface used for communication, consisting of a Send work queue and a Receive 
work queue. 

B.3.2.17 IB service ID: A value that allows an IB communication manager to associate an incoming 
connection request with the entity providing the service. 

B.3.2.18 IB subnet: A set of IB ports connected via IB switches that have a common IB subnet ID and are 
managed by a common IB subnet manager. 

B.3.2.19 IB subnet manager: Entity that configures and controls an IB subnet. See Infiniband™ Architecture 
Specification Volume 1 Release I.O.a. 

B.3.2.20 IPv6 address: A 128-bit address constructed in accordance with IETF RFC 2373 for Internet Protocol 
version 6. See IETF RFC 2373. 

B.3.3 Abbreviations 

CM:Ready To Use IB communication manager Ready to Use message 
CM:Reject IB communication manager Reject message 

CM:Request IB communication manager Request message 

CM:Response IB communication manager Response message 

CRC Cyclic Redundancy Check 

GID IB Global ID 

GUID Globally unique identifier 

IB InfiniBand™ Architecture 

IBAS Infiniband™ Architecture Specification Volume 1 Release I.O.a, Infiniband 

Trade Association (www.infinibandta.org) 

IOC IB 10 Controller 

IPv6 Internet Protocol version 6 

LID IB Local ID 

MAD IB Management datagram 

QP IB Queue pair 

B.4 InfiniBand™ Architecture overview 

InfiniBand™ Architecture devices contain IB consumers and one or more IB channel adapters. Each IB channel 
adapter contains one or more IB ports. Associated with each IB channel adapter are IB QPs that interface 
between IB consumers and the IB channel adapter. Figure B.1 shows an example InfiniBand™ Architecture 
device. 
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Figure B.1 - InfiniBand™ Architecture device example 

An IB I/O unit is an InfiniBand™ Architecture device that contains an IB channel adapter with one or more IB 
ports, IB QPs, and one or more IB I/O controllers. Figure B.2 shows an example IB I/O unit. 



Figure B.2 - IB I/O unit example 
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Each IB port has a 64-bit globally unique identifier called an IB port GUID. Each IB channel adapter has a IB 
channel adapter GUID (which is shared by all IB ports on the IB channel adapter). Each IB I/O controller has an 
IB I/O controller GUID. 

The IB subnet manager assigns one or more IB LIDs and one or more IB GIDs to each IB port. 

Table B.1 summarizes the InfiniBand™ Architecture names (IB GUIDs) and addresses (IDs) relevant to this 
protocol. 
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Table B.1 - InfiniBand™ Architecture names and addresses 


Name 

Scope of 
uniqueness 

Size 

Description 

IB port GUID 

worldwide 

64 bits 

Identifies an IB port 

IB channel adapter GUID 

worldwide 

64 bits 

Identifies a IB channel adapter 

IB I/O controller GUID 

worldwide 

64 bits 

Identifies an IB I/O controller 

IB LID 

IB subnet 

16 bits 

Local routing address assigned to each IB port by 
the IB subnet manager 

IBGID 

varies 3 

128 bits 

Address assigned by the IB subnet manager; (e.g., 

IB subnet prefix plus the IB port GUID) 

3 >Refer to Infiniband™ Architecture Specification Volume 1 Release 1.0.a 
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B.5 SCSI architecture mapping 

Figure B.3 illustrates how SCSI initiator devices, SRP initiator ports, SRP target ports, and SCSI target devices 
map to InfiniBand™ Architecture objects. 



Figure B.3 - SCSI architecture mapping 

The RDMA communication service (see clause 4) includes IB queue pairs, IB channel adapters, IB ports, 
software, and the InfiniBand™ Architecture fabric. 

An IB consumer in any InfiniBand™ Architecture device may be an SRP initiator port. An SRP initiator device 
may consist of one or more IB consumers. The SRP initiator port identifier shall be constructed as shown in 
table B.2. 


Table B.2 - InfiniBand™ Architecture SRP initiator port identifier 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

(MSB) 


IDENTIFIER EXTENSION 

7 

(LSB) 

8 

(MSB) 


guid (e.g., IB channel adapter GUID) 

15 

(LSB) 


The identifier extension field shall be chosen by the SRP initiator port to ensure that all SRP initiator port 
identifiers are unique. 
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The guid field should an IB GUID available to the SRP initiator port. 

SRP target ports shall be implemented by IB 10 Controllers in IB I/O units. The IB I/O unit shall include an IB 
device management agent to provide the lOUnitlnfo, lOControllerProfile, and ServiceEntries attributes. 

An SRP target port is identified by a ServiceEntries attribute of an IB I/O controller. The SRP target port identifier 
shall be constructed as shown in table B.3. 



The identifier extension field shall be the value from the ServiceEntries attribute that identifies the SRP target 
port (see table B.8). 

The io CONTROLLER guid field shall be the IB I/O controller GUID of the IB I/O controller providing the SRP target 
port. 

B.6 Communication management 
B.6.1 Communication management overview 

IB communications managers on each InfiniBand™ Architecture device manage InfiniBand™ Architecture 
connections using IB MADs transported over the IB General Service Interface. SRP initiator ports and SRP 
target ports shall use the active/passive (client/server) connection establishment protocol. The processor unit 
or IB I/O controller containing the SRP target port shall act as the server and the processor unit or IB I/O 
controller containing the SRP initiator port shall act as the client. 

B.6.2 Discovering SRP target ports 

To discover the IB service ID of an SRP target port in an IB I/O unit, an SRP initiator port may use this sequence: 

1. Retrieve the lOUnitlnfo attribute from an IB I/O unit using a DevMgtGet IB MAD to determine the 
presence and slot number of each IB I/O controller attached to the IB I/O unit. 

2. Retrieve the lOControllerProfile attributes from each IB I/O controller, each of which includes a 
ServiceEntries table. 

3. Search the ServiceEntries table for service names matching the rules described in table B.8. 

The IB service ID associated with each matching service name may be used in the communication management 
process to establish InfiniBand™ Architecture connections to IB I/O controllers providing SRP target ports. The 
SRP target port identifier for each SRP target port is constructed as described in table B.3. 

B.6.3 Establishing a connection 

To establish an InfiniBand™ Architecture connection, the client places the IB service ID in an IB communication 
management CM:Request message. The server associates the request with the appropriate SRP target port. 
The PrivateData field of the CM:Request message shall include an SRP_LOGIN_REQ request (see 6.2). 
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The SRP target port may choose to refuse the connection based on the SRP_LOGIN_REQ request content by 
returning a CM:Reject message with the reason code set to Consumer Reject. The PrivateData field of the 
CM:Reject message shall include an SRP_LOGIN_REJ response (see 6.4). 

The SRP target port may choose to redirect the connection to a different endpoint (e.g. another IB port) by 
returning a CM:Reject message with the reason code set to either PORT AND CM REDIRECTION or PORT 
REDIRECTION. The SRP initiator port should retry the connection establishment using the new endpoint. See 
Infiniband™ Architecture Specification Volume 1 Release 1.0.a. 

If the server accepts the connection request and SRP login, the server returns a CM:Response message. The 
PrivateData field of the CM:Response message shall include an SRP_LOGIN_RSP response (see 6.3). The 
SRP initiator port may choose to refuse the connection based on the SRP LOGIN RSP response content by 
returning a CM:Reject message with a Reason code set to Consumer Reject. In this case, the PrivateData field 
of the CM:Reject message is reserved. 

If the client accepts the connection reply and the SRP login response, it replies with a CM:Ready To Use 
message indicating both an InfiniBand™ Architecture and an SRP connection are open. The client may then 
start using the connection for communication. 

B.6.4 Releasing a connection 

The SRP initiator port may send an SRP_l_LOGOUT request or the SRP target port may send an 
SRP_T_LOGOUT request with a SEND operation. The sender shall send a CM Disconnect Request as 
described in IBAS upon receipt of an InfiniBand™ Architecture transport level acknowledgement to the 
SRP_l_LOGOUT request or SRP_T_LOGOUT request information unit. The receiver of an SRP_IJ_OGOUT 
request or SRP_T_LOGOUT request information unit shall respond with an InfiniBand™ Architecture transport 
acknowledgement and may send a CM Disconnect Request as described in IBAS, or may wait to receive a CM 
Disconnect Request. 

B.6.5 Errors 

Some errors cause an IB queue pair to enter the Error state, which destroys the connection. The IB 
communication manager for the queue pair consumer should send a CM Disconnect Request as described in 
IBAS. 

B.6.6 Data-out and data-in operations 

An SRP target port shall map a Receive Data-out SCSI protocol service interface procedure call to one or more 
InfiniBand™ Architecture RDMA READ requests. An SRP target port shall map a Send Data-in SCSI protocol 
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service interface procedure call to one or more InfiniBand™ Architecture RDMA WRITE requests. Table B.4 
specifies the value of the InfiniBand™ Architecture RDMA header fields. 


Table B.4 - InfiniBand™ Architecture RDMA header fields 


InfiniBand™ Architecture RDMA 
Extended Transport Header field 

Value 

Virtual Address 

virtual address 3 + application client buffer offset 13 

Remote Key 

MEMORY HANDLE 0 

DMA Length 

request byte count d 

3 The contents of the virtual address field in the memory descriptor (see table 1). 
b The application client buffer offset parameter to the receive data-out (see table A.4) or send data-in 
(see table A.5) SCSI protocol service interface procedure call. 
c The contents of the memory handle field in the memory descriptor (see table 1). 

d The request byte count parameter to the receive data-out (see table A.4) or send data-in (see table 
A.5) SCSI protocol service interface procedure call. 


B.7 InfiniBand™ Architecture protocol requirements 

SRP target ports and SRP initiator ports shall support the Reliable Connection transport service type. 
SRP target ports shall implement the device management class of general management services. 
SRP initiator ports and SRP target ports shall support the transport functions described in table B.5. 


Table B.5 - Transport operation support requirements 


Transport functions 

SRP initiator port 

SRP target port 

Send to 

Mandatory 

Mandatory 

Send from 

Mandatory 

Mandatory 

RDMA write to 

Mandatory 

Not used 

RDMA write from 

Not used 

Mandatory 

RDMA read to 

Mandatory for 
data-out commands 

Not used 

RDMA read from 

Not used 

Mandatory for 
data-out commands 

RDMA Write with 
immediate data (to or from) 

Not used 

Not used 

ATOMIC (to or from) 

Not used 

Not used 
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IB I/O units containing an IB I/O controller acting as an SRP target port shall report the device management 
lOUnit attributes defined in Infiniband™ Architecture Specification Volume 1 Release I.O.a as described in 
table B.6. 


Table B.6 - lOUnit attributes for SRP target ports 


Field 

SRP requirement 

Max Controllers 

At least one 

Controller List 

At least one IB I/O controller acting as an SRP target port shall be present 

a This protocol does not change or override InfiniBand Architecture requirements on the 
values of fields not listed. 


IB I/O controllers acting as SRP target ports shall report the device management lOControllerProfile attributes 
defined in Infiniband™ Architecture Specification Volume 1 Release I.O.a as described in table B.7. 
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Table B.7 - lOControllerProfile attributes for SRP target ports 


Field 

SRP requirement 

I/O Class 

OlOOh 

I/O Subclass 

609Eh 

Protocol 

0108h 

Protocol Version 

0001 h 

Service Connections 

At least one 

Initiators Supported 

At least one 

Send Message Depth 

Reserved 

RDMA Read Depth 

Maximum IOC-issued RDMA depth 3 

Send Message Size 

MAXIMUM INITIATOR TO TARGET IU SIZE b 

RDMA Transfer Size 

Reserved 

Controller Operations Capability Mask: 


0: ST; Send Messages To lOCs 

Shall be set to one. 

1: SF; Send Messages From lOCs 

Shall be set to one. 

2: RT; RDMA Read Requests To lOCs 

No requirement 

3: RF; RDMA Read Requests From lOCs 

Shall be set to one if an SRP target port supports 
data-out commands. No requirement otherwise. 

4: WT; RDMA Write Requests To lOCs 

No requirement 

5: WF; RDMA Write Requests From lOCs 

Shall be set to one. 

6: AT; Atomic Operations To lOCs 

No requirement 

7: AF; Atomic Operations From lOCs 

No requirement 

Controller Services Capability Mask 

Reserved 3 

Service Entries 

At least one 

3 This protocol does not change or override InfiniBand Architecture requirements on the values 
of fields not listed, or for those marked as having ’no requirement’. 
b The largest number of RDMA Read requests that this 10 Controller may have outstanding on 
one channel. 

c This value shall be no less than the largest value, in bytes, of MAXIMUM INITIATOR TO 
TARGET IU SIZE that this 10 Controller shall return in the SRP LOGIN RSP information unit. 
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IB I/O controllers providing SRP target ports shall include at least one ServiceName/ServicelD pair in the device 
management ServiceEntries attribute pair (see IBAS) as described in table B.8. 


Table B.8 - ServiceEntries attribute pair for SRP target ports 


Field 

Length (bits) 

SRP requirement 



’SRP.T 10 xxxxxxxxxxxxxxxx’ 

ServiceNamen 

320 

or 

’SRP.T10:xxxxxxxxxxxxxxxx:reserved’ 

ServicelD_n 

64 

Assigned by the IB I/O controller 


a A service name that identifies an SRP target port shall meet the rules 
described in this table. 


b The string ’SRP.T10’ and the colons shall appear exactly as shown (e.g. 
capital letters only). 

c The string ’xxxxxxxxxxxxxxxx’ in the service name shall be sixteen 
hexadecimal digits. Only the characters 0 to 9 and A to F (capital letters 
only) are permitted. If any other character appears the service name 
shall not be recognized as identifying an SRP target port. 
d The string ’xxxxxxxxxxxxxxxx’ in the service name identifies the 64-bit 
extension identifier value used to construct the SRP target port identifier 
(see table B.3) 

e The literal string ’reserved’ shall either be ignored by SRP initiator ports 
or treated in accordance with a future revision of this standard. 
f If the service name does not completely fill ServiceName_n field (i.e. it is 
less than 40 bytes), it shall be extended with null characters (i.e., binary 
zeros). 
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Annex C 

(normative) 

SRP for iWARP 

C.1 Overview 

This annex specifies requirements for mapping SRP onto iWARP, which provides RDMA services over TCP/IP. 

C.2 Normative references 


C.3 Definitions and abbreviations 
C.3.1 Definitions 
C.3.2 Abbreviations 
C.4 iWARP overview 
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